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

Search Results: 99 of 247 [ <<First <Prev Next> Last>> ] [ Return to Search Results ]

* Your Email Address
* Spam protection	Enter the letters below: \ / ..__..___. . >< \|\| \|[__ \|\ \| / \\__\|\|__\[___\| \\|
Comment	> 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. >
Attachment
Watch this ticket

Saved Queries