4 ms·

I implemented a date time library for JS a few years ago and took heavy inspiration from java.time. My conclusion is that the time zones are the hardest part of

by dexwiz 5y ago

I implemented a date time library for JS a few years ago and took heavy inspiration from java.time. My conclusion is that the time zones are the hardest part of the whole thing. Time zones are defined by political entities that doesn’t give two cents about implementing them. Also there is a huge variance in their details so just because you understand time zones in X country, don’t assume that knowledge is universal. Some of my favorites are timezone changes at midnight, so 1159>1am, meaning some days lack a midnight. Also some Muslim countries switch back to normal time for Ramadan, which means up to 4 changes in a single year. Also anyone trying to sell “Midnight GMT” as a date only format is in for a world of trouble down the line.

FranksTV 5y ago
Plus the historical changes in timezones and dates. Not only are they bonkers, but they're bonkers in different ways depending on the year.
- dexwiz 5y ago
  If you get a chance read through the IANA Timezone date base files. It has all sorts of interesting tidbits related to this.
blago 5y ago
I'm genuinely interested in learning more about the problems that midnight-GMT-as-date-only can lead to. It's used on a project I currently work on. Do you have a link or can you spare a few minutes to explain?
- dexwiz 5y ago
  Generally you end up with some “apply offset” code that tries to convert between an date time and a date by applying the timezone offset. This generally works but is full of edge cases. For example on days with DLS changes the offset is not the same throughout the day, so you need extra logic to figure out what is the correct offset. Also most code is usually only tested in the dev’s timezone. So you can write code that works in a negative offset but has bugs in positive offsets or vice versa. Another issue is the mental burden of knowing when a time stamp is supposed to be a date or a date time. You cannot write a reliable method to differentiate them because there will be valid date times that are exactly at GMT midnight. Fundamentally dates and date times (instants) are different. Christmas is December 25th in Australia and the USA. But the instants that those time zones experience that date are different. People forget this and will try to treat the GMT midnight as a date time, when it should be a date.

by dexwiz 5y ago

FranksTV 5y ago

Plus the historical changes in timezones and dates. Not only are they bonkers, but they're bonkers in different ways depending on the year.

dexwiz 5y ago
If you get a chance read through the IANA Timezone date base files. It has all sorts of interesting tidbits related to this.

blago 5y ago

I'm genuinely interested in learning more about the problems that midnight-GMT-as-date-only can lead to. It's used on a project I currently work on. Do you have a link or can you spare a few minutes to explain?

dexwiz 5y ago
Generally you end up with some “apply offset” code that tries to convert between an date time and a date by applying the timezone offset. This generally works but is full of edge cases. For example on days with DLS changes the offset is not the same throughout the day, so you need extra logic to figure out what is the correct offset. Also most code is usually only tested in the dev’s timezone. So you can write code that works in a negative offset but has bugs in positive offsets or vice versa. Another issue is the mental burden of knowing when a time stamp is supposed to be a date or a date time. You cannot write a reliable method to differentiate them because there will be valid date times that are exactly at GMT midnight. Fundamentally dates and date times (instants) are different. Christmas is December 25th in Australia and the USA. But the instants that those time zones experience that date are different. People forget this and will try to treat the GMT midnight as a date time, when it should be a date.