Issue with Date constructor

[Peter Sheldon]

I am using Ebase 5.9.0 Build 2020814.

A bug was recently reported in the one of our forms. It affects the initialisation of certain dates when a text string is used.

Both of these work fine:
fields.TEST_DATE.value = new Date('October 05, 1945');
fields.TEST_DATE.value = new Date('1945/10/05');

However both of the following initialise with 07/10/1945 23:00, ie. losing one hour.
fields.TEST_DATE.value = new Date('October 08, 1945');
fields.TEST_DATE.value = new Date('1945/10/08');

I found a lot of other dates which were initialising wrongly. It doesn't matter whether TEST_DATE is a date or a date/time field.
The other Date constructors don't seem to have the same problem.

Possibly it may have something to do with BST (British Summer Time) /GMT (Greenwich Mean Time)

Another example where I have seen this 'wrong by one hour' problem is with all the dates from 5/10/1959 - 25/10/1959 (inclusive).

Is there a simple fix for this issue?

Regards,
Peter

[Peter Sheldon]

My colleague Chris has noticed that if you run this code in a browser:

var dt = new Date('October 05, 1945');
alert(dt);
-> Fri Oct 05 1945 00:00:00 GMT+0100 (British Summer Time)
Note that it is BST, whereas

var dt = new Date('October 08, 1945');
alert(dt);
-> Mon Oct 08 1945 00:00:00 GMT+0000 (Greenwich Mean Time)
Note that it is now GMT, the clocks have gone back!

(but the date is still correct, when run in a browser)

Is it possible therefore that it is the Rhino Javascript engine which is getting confused?

Regards,
Peter

[Peter Sheldon]

Our version of Rhino is 1.7.11 2019 07 19

To see the Rhino version, we ran this Javascript:

var Context = org.mozilla.javascript.Context;
var currentContext = Context.getCurrentContext();
var rhinoVersion = currentContext.getImplementationVersion();
log('Rhino version = ' + rhinoVersion);

Regards,
Peter

[Steve]

Hi Peter,

I am having a look at this now. I need to establish whether the problem is with these historical dates:

1) With the Java API
2) Rhino
3) ICU4J

I will run some tests now to try and located the issue.

Kind regards

Steve

[Steve]

As responded in the support ticket:

I have done various tests and I conclude that this is a problem with NativeDate inside the Rhino Engine.

The reason appears that if the timezone is missing from the String the Rhino NativeDate class. In the case of 8th October 1945, Rhino is adjusting to UTC and removing an hour and setting the time to 07 October 1945 23:00

I think that this is a bug with Rhino.

You have a couple of options:

Removing the timeZoneOffset from the minutes appears to set the date correctly:

var d = new Date('October 08, 1945');
d.setMinutes(d.getMinutes() - d.getTimezoneOffset());
fields.TEST_DATE.value = d;

But you may find that times on BST are set to 1:00 in the morning, which maybe unacceptable.

Another option is to append 12:00 to the date and just set the time to midday.. this way the date will not be the wrong day as the time will be 11:00:

var d = new Date('October 08, 1945 12:00');
fields.TEST_DATE.value = d;

I do not think that Rhino will be fixing this problem, as it appears to effect historical dates that have been adjusted, for example WW2 dates

Steve