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
Issue with Date constructor
Moderators: Jon, Steve, Ian, Dave
-
- Ebase User
- Posts: 5
- Joined: Fri Oct 13, 2017 11:55 am
Re: Issue with Date constructor
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
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
0 x
-
- Ebase User
- Posts: 5
- Joined: Fri Oct 13, 2017 11:55 am
Re: Issue with Date constructor
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
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
0 x
-
- Moderator
- Posts: 415
- Joined: Fri Sep 07, 2007 3:44 pm
- Location: Sandy, UK
- Contact:
Re: Issue with Date constructor
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
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
0 x
-
- Moderator
- Posts: 415
- Joined: Fri Sep 07, 2007 3:44 pm
- Location: Sandy, UK
- Contact:
Re: Issue with Date constructor
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
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
0 x
Who is online
Users browsing this forum: No registered users and 15 guests