Jasmine .toHaveBeenCalledWith(aDate) not working - testing

I'm inheriting some code, and I've got two of their tests that are still failing, not sure if they were before, or if it's because I have a different version of Jasmine (they were pre 2.0)
The test that is failing has this spy setup in the beforeEach
spyOn(datacontext, 'getImportLogForDate').and.callThrough();
Then in the test
controller.DepositDate = new Date();
controller.PerformActionThatCallsGetImportLogForDate();
expect(context.getImportLogForDate).toHaveBeenCalledWith('1', controller.DepositDate);
The resulting error is confounding because they are identical
Expected spy getImportLogForDate to have been called with [ '1', Date(Thu Dec 04 2014 13:00:51 GMT-0600 (Central Standard Time)) ] but actual calls were [ '1', Date(Thu Dec 04 2014 13:00:51 GMT-0600 (Central Standard Time)) ].
Can I not verify functions have been called with a Date?

What is PerformActionThatCallsGetImportLogForDate doing with the date object? Jasmine compares date objects by their millisecond value so if it's off even by 1ms, they won't be equal, but you won't see that level of detail just reading the console output.
Alternatively, you have 2 other options.
Just test that a date object was used as the 2nd argument.
expect(context.getImportLogForDate)
.toHaveBeenCalledWith('1', jasmine.any(Date));
Test that date value, but outside of a toHaveBeenCalledWith, in case of some specific weirdness with that matcher.
expect(context.getImportLogForDate.calls.mostRecent().args[0])
.toEqual('1');
expect(context.getImportLogForDate.calls.mostRecent().args[1])
.toEqual(controller.DepositDate);

I have found that when using toHaveBeenCalledWith for a specific Date, jasmine.objectContaining works great.
it('#userChangedMonth calls fetchData with end of month', () => {
spyOn(component, 'fetchData').and.returnValue(true);
const calendarChangedTo = new Date('2018-10-10 00:00:00');
const endOfMonth = new Date('2018-10-31 23:59:59');
component.userChangedMonth(calendarChangedTo);
expect(component.fetchData).toHaveBeenCalledWith(jasmine.objectContaining(endOfMonth));
});

Related

React native : moment not working for specific time value without debug mode

I have below code where I format the time value to be date format.
const arrivalDateTime = moment(
`${todaysDate.format("YYYY-MM-DD")} ${arrivalTime}:00:00`,
).toDate();
When debug mode is off, if I select 8 or 9 value from the control, its not able to format the value.
When I am in debug mode, and select 8 or 9, its able to format the value as:
Fri May 22 2020 09:00:00 GMT-0600 (Mountain Daylight Time)
I have seen many threads discussing the same issue but solution provided in them haven not helped me to format this correctly.
I am trying to print arrivalDateTime value, it shows like this in log ;
Date { NaN }
I am trying this but it does not work, it days toDate is not a function :
moment().format(`YYYY-MM-DD ${arrivalTime}:00:00`).toDate();
Took me a while but I finally figured it out.
this helped me
This didn't work:
const arrivalDateTime = moment(
`${todaysDate.format("YYYY-MM-DD")} ${arrivalTime}:00:00`,
).toDate();
This worked:
const arrivalDateTime = moment(
`${todaysDate.format('YYYY/MM/DD')} ${arrivalTime}:00`,
).toDate();
// note that engine does not seem to like parsing with ' - '. so I changed it to ' / '
still not sure the reason behind it.

Moment format the time will become invalid date without debug mode on React Native

moment version is 2.24.0
My date value is 2019-04-23 03:16:00 +0000 UTC
I use moment to let it become to Asia time just like:
const moment = require('moment');
const localTime = moment(date).format('YYYY/MM/DD HH:mm');
<Text>{localTime}</Text>
localTime will show 2019/04/23 11:16
It works when I test it on debug mode.
But when I close the debug mode localTime will be
invalid date
The issue happen both of Android and IOS.
Any ideas ?
For anyone else experiencing date/time issues with Moment on Android especially if you're moving from React Native 0.59 (or older) to 0.60+, it appears that Hermes changes the way the Android works with Moment/dates. However, it would work when the debugger was enabled. Turns out, when you run the debugger, it switches back to the Chromium engine (or V8?) from Hermes. Resulted in us having to use console logs to track down Moment parsing issues. Oddly, the issues also occurred when trying the same manipulations in Safari.
If you're parsing dates passed in via different vars for day, month, year and the day or month does not have preceding zeroes (ex: 01 vs 1) then I recommend doing this:
const momentFormat = { y: birthYear, m: birthMonth, d: birthDay };
return Moment(momentFormat).format('MMMM Do, YYYY');
This manually sets the values rather than relying on each value being correctly formatted or having to write custom code to ensure the day/month values have the 0 when needed.

phantomjs parses dates incorrectly for dates before March in the year of 1400, why?

Is it some sort of overflow?
phantomjs> new Date("1400-03-01T00:00:00.000Z")
"1400-03-01T00:00:00.000Z"
phantomjs> new Date("1400-02-28T20:59:59.000Z")
"1400-02-27T20:59:59.000Z"
what you would expect:
>>(new Date("1400-03-01T00:00:00.000Z")).toISOString()
"1400-03-01T00:00:00.000Z"
>>(new Date("1400-02-28T20:59:59.000Z")).toISOString()
"1400-02-28T20:59:59.000Z"
apparently there is a gap of 24 hours when parsing dates between the 28th of February in 1400 and the 1st of March in 1400.
any ideas?
Phantomjs anyway is obsolete but still ... our legacy tests are failing when we try to upgrade to chrome headless ...
PhantomJS uses a version of Qt WebKit which is maintained independently of Qt.
The date format you are using is part of the ISO-8601 date and time format. [related]
The version of Qt WebKit that PhantomJS uses has a function that parses dates of the form defined in ECMA-262-5, section 15.9.1.15 (similar to RFC 3339 / ISO 8601: YYYY-MM-DDTHH:mm:ss[.sss]Z).
In the source code, we can see that the function used to parse these types of dates is called:
double parseES5DateFromNullTerminatedCharacters(const char* dateString)
The file that contains this function in the PhantomJS repository has not been updated since July 27, 2014, while the official file was updated as recently as October 13, 2017.
It appears that there is a problem in the logic having to do with handling leap years.
Here is a comparison of DateMath.cpp between the most recent versions from the official qtwebkit repository (left) and the PhantomJS qtwebkit repository (right).

DateTime.ToLocalTime() stopped working on XP in August 2013

We have a VB.NET application installed on a customer's PC running XP, on which it appears that DateTime.ToLocalTime() has stopped working.
The problem first manifested itself in August 2013.
The customer is based in Texas, and their timezone is correct.
The documentation for DateTime.ToLocalTime() has the following interesting note:
On Windows XP systems, the ToLocalTime method recognizes only the current adjustment rule when converting from UTC to local time. As a result, conversions for periods before the current adjustment rule came into effect may not accurately reflect the difference between UTC and local time.
Therfore it appears likely that a timezone rule change was introduced in the August Windows Update, which has caused this.
I've found the following: http://support.microsoft.com/kb/2863058 which indicates that a cumulative timezone update was applied in August 2013, but no USA rules seem to be implicated in this change.
Has anyone else had experience of this problem, and (of course) a solution?
Edit
To clarify a bit. The times in question are stored in UTC in a SQL database, and we're converting to LocalTime for display. It's the display which is causing the problem.
Events which were recorded at 1500 localtime are now showing as recorded at 2100.
Will you be able to recode the product for the client?
You can use the Format function or the DateTime.Now, which gives you the date and time details of the local computer
Here give it a try:
Textbox1.text = DateTime.Now.ToString("yyyy-MM-dd hh:mm:ss tt")
Textbox1.Text = Format(now, "yyyy-MM-dd hh:mm:ss")
you can change the date time details inside the string, just remember y=year, M=month, d=day, h=hour, m=minute, s=seconds.
If you have a back end database though, I'd recommend getting the time from it. (which would depend on the database)
This is just a guess, since you didn't show any code. (Please show code in your questions, it makes it much easier to help!)
Texas is currently in Central Standard Time, which is UTC-6. Since there are 6 hours difference between the times you reported (1500, 2100), my guess is that you are converting twice somehow.
This shouldn't happen under normal conditions, thanks to the .Kind property attached to the DateTime. For example:
DateTime dt1 = new DateTime(2013, 11, 22, 3, 0, 0, DateTimeKind.Utc);
Debug.WriteLine("{0:HH:mm} ({1})", dt1, dt1.Kind); // 3:00 (Utc)
DateTime dt2 = dt1.ToLocalTime();
Debug.WriteLine("{0:HH:mm} ({1})", dt2, dt2.Kind); // 21:00 (Local)
DateTime dt3 = dt2.ToLocalTime();
Debug.WriteLine("{0:HH:mm} ({1})", dt3, dt3.Kind); // 21:00 (Local)
But if somehow you loose track of the kind and it is set back to "unspecified", then the double conversion can happen:
DateTime dt1 = new DateTime(2013, 11, 22, 3, 0, 0, DateTimeKind.Utc);
Debug.WriteLine("{0:HH:mm} ({1})", dt1, dt1.Kind); // 3:00 (Utc)
DateTime dt2 = dt1.ToLocalTime();
Debug.WriteLine("{0:HH:mm} ({1})", dt2, dt2.Kind); // 21:00 (Local)
// somehow, the kind is getting set back to unspecified in your code
dt2 = DateTime.SpecifyKind(dt2, DateTimeKind.Unspecified);
DateTime dt3 = dt2.ToLocalTime();
Debug.WriteLine("{0:HH:mm} ({1})", dt3, dt3.Kind); // 15:00 (Local)
Now, it's unlikely that you are actually calling DateTime.SpecifyKind. Instead, I'd be looking in your code for some place where you store the local time back to the DB instead of the UTC time.
Or it could be that you convert the local DateTime to a string and read it back to another DateTime by parsing that string. That can happen in UI code. Perhaps you need to specify Local kind when gathering from a user on a form?
You should debug your code and step through so you can see how it is being transformed. I think then you will find the answer.
No, nothing happened in the Aug 2013 Windows Time Zone update that would affect the United States. The last DST change in the US was in 2007. Even then, you would be off by 1 hour, not 6.

Facing a problem with GWT Data Serialization

This is similar to the question: GWT Data Serialization
I am using Date Object # my client,
Here is what I tried,
I created a Date Object, showed its toString() in a Label and passed it to server via Rpc whose return value is the same Date's toString()
value passed:
Date value = new Date(2011, 0, 19);
Output # Hosted/Development mode : (http://127.0.0.1:8888/MyApplication.html?gwt.codesvr=127.0.0.1:9997)
Client Reads: Thu Jan 19 00:00:00 IST 3911 Server reads:Thu Jan 19 00:00:00 IST 3911
Output # Production mode (after GWT compile) : (http://127.0.0.1:8888/MyApplication.html)
Client Reads: Thu Jan 19 00:00:00 GMT+530 3911 Server reads:Thu Jan 19 00:00:00 IST 3911
Output # Deploying in Jboss running in the same Machine :
Client Reads: Thu Jan 19 00:00:00 GMT+530 3911 Server reads:Wed Jan 18 18:30:00 GMT 3911
What's mind boggling is that its the same machine and hence the locale, etc should ideally be the same, still # hosted mode I see client sends IST server receiving IST, #production I see client sends GMT server receives IST and #Jboss server deploy I see client sends GMT and server receives GMT with one Day less !!
The fact that the server recieves one day less is very seriously affecting my application business logic, basically I am using iBatis thats populating my pojos from database and sending it to client and at client I am using GXT which is showing me a UI for date selection.
Using String for date is not suitable for me since its a major change in application core pojos, all database select and insert queries just because my client library does not handle Dates well.
Does anyone have a alternative to this ?
You can try to use DateTimeFormat to build something that is unambiguous among machines despite locales. Format like 'yyyy-MM-dd HH:mm:ss ZZZZ' instead of using toString()
Date today = new Date();
DateTimeFormat fmt = DateTimeFormat.getFormat("yyyy-MM-dd HH:mm:ss ZZZZ");
GWT.log(fmt.format(today));