[Tickets #13947] Re: Calendar breaks on DST start date

Tue Nov 14 00:24:02 UTC 2017

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: https://bugs.horde.org/ticket/13947
------------------------------------------------------------------------------
  Ticket             | 13947
  Updated By         | lfbm.andamentos at gmail.com
  Summary            | Calendar breaks on DST start date
  Queue              | Kronolith
  Version            | 4.2.2
  Type               | Bug
  State              | Feedback
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------

lfbm.andamentos at gmail.com (2017-11-14 00:24) wrote:

Although latest Datejs release is 10 years old and probably should not  
be used anymore, this is not a bug with it. Nor it's a bug with Horde.

ECMAScript does not have specs regarding what happens when a local  
time is set to an invalid moment. So each browser deals with it on its  
own way.

In 2017, Brazil shifts to DST at 2017-10-14, precisely at the end of  
23:59. So just before the clock turns to 00:00, it jumps do  
2017-10-15, 01:00. So it creates a gap of missing local time.

Other countries do the same thing at 23:59 (Lebanon, Syria) and  
others, such as US, do it at 02:00, when it jumps to 03:00, and others  
do it at different moments. Every country that has DST will have gaps  
of missing local times. The site www.timeanddate.com is the best  
reference there is.

So when you try to create a date at an invalid moment in local time  
with Chrome, for example, it will jump to the next day:

new Date(2017, 9, 15, 0, 0).toString();
?Sun Oct 15 2017 01:00:00 GMT-0200 (-02)?

Here, I set my computer to Brazil standard time and tried to ask  
Chrome what is the local time in 2017-10-15 (9 is October because the  
counter starts with 0), at midnight (00:00). Since midnight does not  
exist on 2017-10-15, Chrome has jumped to 2017-10-15 01:00 and gave me  
that answer.

If I do the same thing with Firefox, it jumps back to the day before:

new Date(2017, 9, 15, 0, 0).toString();
"Sat Oct 14 2017 23:00:00 GMT-0300"

So in various parts of kronolith.js, when it tries to create moments  
at invalid local times, things get broken depending on the user's  
browser and moment in time. This is also the reason why adding one day  
to 2017-10-14 00:00 will return a result of 2017-10-14 23:00, instead  
of 2017-10-15 00:00, when the user is on Firefox.

This is causing the day 2017-10-14 to appear duplicated in kronolith  
dynamic view, as reported in the original post.

The Horde Calendar Picker will also not let you select the day  
2017-10-15, because, such as Datejs, it always defaults new date  
objects to midnight (00:00) and, as seen above, the moment 2017-10-15  
00:00 simply does not exist in some local times. So when you select  
2017-10-15 it returns 2017-10-14, if your computer is set to any date  
before entering Brazil (and similar countries) DST.

This is why when a JS program is interested only in dates (not time)  
and date calculations, it should *never* trust local time. It should  
always use UTC time, because there are no gaps nor overlaps in UTC.

Another way of working around this issue is to default date creations  
to 12:00, because no DST transitions ever occur in the middle of the  
day, in any time zone. So it?s a safer way of doing date calculations  
when the choice of trusting local times had already been made in the  
first place.

Unfortunately, Datejs is old and abandoned and does not have full UTC support.

Moment.js (https://momentjs.com/) is a much better choice and updated  
library. It also has a nice feature which is the UTC mode. While in  
UTC mode, all display methods will display in UTC time instead of  
local time. Additionally, while in UTC mode, all getters and setters  
will internally use the Date#getUTC and Date#setUTC methods instead of  
the Date#get and Date#set methods  
(https://momentjs.com/docs/#/parsing/utc/). This way you won?t have to  
trust local time when dealing with date calculations.

The best solution here, IMHO, would be to rewrite the parts of  
kronolith the uses Datejs and make it use moment.js, activating the  
UTC mode when necessary.

It should be possible to patch kronolith.js in order to make it create  
dates at 12:00 (midday), when time does not matter, instead of  
midnight. But the first solution (moment.js with UTC mode) seems more  
elegant.

Anyway, this is definitely something that cannot be ignored by horde,  
because different browser deals with invalid local times in different  
manners and it does not seem to change in a near future.