Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why are 2025/05/28 and 2025-05-28 different days in JavaScript?

brandondong.github.io

Post reply on HN
Print view View original

131–140 of 167 posts

Re: Why are 2025/05/28 and 2025-05-28 different days in JavaScript?

#131

Post by bbojan »

hughw wrote: post #111
tluse wrote: post #12

Earlier quoted context omitted.

Pro tip: never ever use anything but ISO dates in UTC tz unless you're displaying it for a user in a UI.

Some use cases really do require the local TZ offset be saved. Transforming everything to UTC wipes out that information. An engineer in the US reviewing industrial measurements logged in a plant in Asia from a variety of sources is definitely going to encounter lots of events recorded in local time. It would be maddening for that engineer to have to review and resolve events from different time coordinates, especial…

You mean you must record the timezone? Because the TZ offset can change throughout the year (e.g. due to daylight saving time).

Re: Why are 2025/05/28 and 2025-05-28 different days in JavaScript?

#133

Post by hughw »

bbojan wrote: post #131
hughw wrote: post #111

Earlier quoted context omitted.

Some use cases really do require the local TZ offset be saved. Transforming everything to UTC wipes out that information. An engineer in the US reviewing industrial measurements logged in a plant in Asia from a variety of sources is definitely going to encounter lots of events recorded in local time. It would be maddening for that engineer to have to review and resolve events from different time coordinates, especial…

You mean you must record the timezone? Because the TZ offset can change throughout the year (e.g. due to daylight saving time).

Usually the TZ offset is enough. The use case is a guy reading notes and logs from multiple sources. All that guy needs is to see the local time at the time and place of the event. So that, for example, he can match up the time stamp on some computer recorded log with the time some human operator recorded, in local time, on a paper record.

Re: Why are 2025/05/28 and 2025-05-28 different days in JavaScript?

#134

Post by mzl »

christina97 wrote: post #118
davejohnclark wrote: post #114

Earlier quoted context omitted.

There's a good post about why this isn't as foolproof an approach as it might first seem here https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a...

The post doesn’t account for the case where a suburb of Amsterdam breaks off from the rest of Netherlands and changes timezones… Then how do you know if the event was in the neighborhood or not? My point is that this is an extremely niche case and works around one particular type of timezone insanity. You either have a team dedicated to dealing with timezone insanity, or you store stuff in UTC.

No, but that is an even less likely situation, compared to the problems that the approach advocated for by Jon Skeet actually solves.

Re: Why are 2025/05/28 and 2025-05-28 different days in JavaScript?

#135

Post by mzl »

mytailorisrich wrote: post #115
dotancohen wrote: post #103

Earlier quoted context omitted.

> never ever use anything but ISO dates in UTC tz unless you're displaying it for a user in a UI. Not good for storing future meeting times. DST switchover dates can change, and your tz-normalized date won't change with it.

To me that an UI/UX issue. Internally everything is stored and handled in TAI (better than UTC as no discontinuity) and translated from/to something else for human consumption. I.e. for instance your should have logic to figure out what TAI period corresponds to "next month's meetings" if that's what the user wants, which you apply immediately on user inputs and then forget about DST, time zones, etc. in the rest of…

No, it is not. It is because converting to UTC loses information that can't be retrieved.

Re: Why are 2025/05/28 and 2025-05-28 different days in JavaScript?

#136

Post by nomdep »

dotancohen wrote: post #110
aloha2436 wrote: post #14

Earlier quoted context omitted.

Safari is too valuable of a platform for web developers to ignore, but otherwise yes it's the only real exception to the Chrome monopoly and still certainly much smaller in terms of absolute users.

I use Firefox on all my devices.

Mozilla is no longer a better actor than Google or Apple, just smaller

Re: Why are 2025/05/28 and 2025-05-28 different days in JavaScript?

#137

Post by [deleted] »

mzl wrote: post #135
mytailorisrich wrote: post #115

Earlier quoted context omitted.

To me that an UI/UX issue. Internally everything is stored and handled in TAI (better than UTC as no discontinuity) and translated from/to something else for human consumption. I.e. for instance your should have logic to figure out what TAI period corresponds to "next month's meetings" if that's what the user wants, which you apply immediately on user inputs and then forget about DST, time zones, etc. in the rest of…

No, it is not. It is because converting to UTC loses information that can't be retrieved.

[deleted]

Re: Why are 2025/05/28 and 2025-05-28 different days in JavaScript?

#140

Post by poincaredisk »

hnbad wrote: post #55
divan wrote: post #36

WAT [1] [1] https://www.destroyallsoftware.com/talks/wat

It's a good talk but it's an even better talk if you actually like JS and understand not only why those things are the way they are but also that you wouldn't ever do them in normal code.

You wouldn't do them intentionally, but they're there waiting to bite you in the foot.
Post reply on HN