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

111–120 of 167 posts

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

#111

Post by hughw »

tluse wrote: post #12
Y_Y wrote: post #7

Hang on, slashes and year-month-day? https://en.wikipedia.org/wiki/ISO_8601 Handed down by the ISO, The Great Compromise allows YYYY-MM-DD (or YYYYMMDD if you're in a hurry) but the version with slashes I'd find ambiguous and upsetting, especially early in the month. The standard is good, and you can get it from `date -I`. Hell mend anyone who messes with the delimiters or writes the year in octal or any other heresy…

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, especially if they are doing the review months or years later. It's best to accept that reality and adopt local time as the standard. Then you must record the TZ offset per UTC in any new system you create.

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

#113

Post by dotancohen »

stevoski wrote: post #100

I find it fascinating that JavaScript has so many "WTF?" things like this, and yet is so incredibly successful. Being available everywhere (as far as browsers are concerned) trumps almost all other factors.

Photographers have a saying: The best camera in the world, is the camera you have on you.

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

#114

Post by davejohnclark »

tluse wrote: post #12
Y_Y wrote: post #7

Hang on, slashes and year-month-day? https://en.wikipedia.org/wiki/ISO_8601 Handed down by the ISO, The Great Compromise allows YYYY-MM-DD (or YYYYMMDD if you're in a hurry) but the version with slashes I'd find ambiguous and upsetting, especially early in the month. The standard is good, and you can get it from `date -I`. Hell mend anyone who messes with the delimiters or writes the year in octal or any other heresy…

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

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...

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

#115

Post by mytailorisrich »

dotancohen wrote: post #103
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.

> 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 the code and storage.

Another benefit is that if your user was in New York but is now in London it is trivial and well-constrained to adjust to local time.

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

#116

Post by kccqzy »

normie3000 wrote: post #66
PokerFacowaty wrote: post #45

I recently spent 2 hours on finding the bug, precisely because JS can't comprehend dates/times without a Unix timestamp underneath. I'd take a date from Postgres as e.x. "2025-05-24" and the first time somewhere deep in the package I was using, when JS encountered that, it needed to add a time (midnight, that's sane) and timezone (local time :) ). I was trying to use UTC everywhere and since the read dates had midnig…

> it needed to add a time (midnight, that's sane) Is it sane? Is midnight at the start of a day, or the end of it? I'd think noon would be less ambiguous, and significantly less prone to these timezone issues (although this may not be a benefit).

Indeed it is not sane. Languages should provide a separate Day type to operate on dates without times. Forcing everything to use dates with times and timezones causes bugs in applications that don't need times.

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

#117

Post by mytailorisrich »

tluse wrote: post #12
Y_Y wrote: post #7

Hang on, slashes and year-month-day? https://en.wikipedia.org/wiki/ISO_8601 Handed down by the ISO, The Great Compromise allows YYYY-MM-DD (or YYYYMMDD if you're in a hurry) but the version with slashes I'd find ambiguous and upsetting, especially early in the month. The standard is good, and you can get it from `date -I`. Hell mend anyone who messes with the delimiters or writes the year in octal or any other heresy…

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

TAI is even better as it is continuous without leap seconds.

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

#118

Post by christina97 »

davejohnclark wrote: post #114
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.

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.

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

#119

Post by guffins »

names_are_hard wrote: post #90
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.

What if you're storing a calendar date, such as a birthday? A timestamp is inappropriate, and it's meaningless to discuss timezones in this context. (Example - you want to know if a person is old enough to buy cigarettes, and you need to store a birthday that you can compare against the current day to see if they're legally 18 - if you store an epoch at UTC, do you store the time of day they were born? That's not the…

That’s a great question. ISO 8601 doesn’t allow timezone offsets on date-only strings.

If you were born in the US, can you buy cigarettes at 12:00 am on your 18th birthday in London?

I’ve never heard of age verification laws caring what timezone you were born in. In fact, you couldn’t even pinpoint this from many people’s ID cards. Plenty of US states span multiple time zones, and I wouldn’t be that surprised if there were a maternity ward out there sitting on a TZ line.

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

#120

Post by mytailorisrich »

names_are_hard wrote: post #90
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.

What if you're storing a calendar date, such as a birthday? A timestamp is inappropriate, and it's meaningless to discuss timezones in this context. (Example - you want to know if a person is old enough to buy cigarettes, and you need to store a birthday that you can compare against the current day to see if they're legally 18 - if you store an epoch at UTC, do you store the time of day they were born? That's not the…

If you want to store a date you don't need to store a time, time zone, etc. and your question goes away.

Certainly if you want to store birth dates and do age verification there is no point bothering with these issues, just store calendar date. Trivial to get date for age limit purposes.

Post reply on HN