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

101–110 of 167 posts

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

#101

Post by [deleted] »

Y_Y wrote: post #9
bandrami wrote: post #6

How did they manage to build the entire modern Web on a language without a standard library?

There's even worse language language for this. It's absolutely essential for an modern e-commerce, but has no official standard or spec, many thousands of libraries but they're mostly poorly maintained and geoblocked. The language itself is just a hodge podge of other languages that were popular in the past, and as a result it's worse than Perl for having too many ways to do any single thing. The major dialects may b…

[deleted]

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

#102

Post by dghf »

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…

> Hang on, slashes and year-month-day?

I believe slashes are the most common separators in Japan (which uses that order), at least when explicit kanji for "year", "month" and "day" aren't used.

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

#103

Post by dotancohen »

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.

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

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

#104

Post by isleyaardvark »

ryao wrote: post #95
alexey-salmin wrote: post #81

Earlier quoted context omitted.

There's no reliable way to map it back into the local time in the past, unless you also safe the UTC offset.

If you record them with some known UTC offset regardless of localtime (e.g. 0), you can convert to local time in the past.

The problem with that is you lose the localtime information, which you may want. Say you have recorded the localtime with the known UTC offset of 0, and that localtime is midnight UTC. Now you want to map it back to a localtime in the past. Ok, which localtime? Was it 8pm in NYC? Or was it 5pm in LA? Is the assumption that the localtime is wherever the user is right now, and is that a valid assumption? If the user has traveled to a different timezone, the time is now being converted to a localtime in the past that is different than it actually was when it happened.

edit: another commenter shared this link with an example: https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a...

I like their "Principle of preserving supplied data".

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

#105

Post by FrancoisBosun »

mariusor wrote: post #75
Scarblac wrote: post #58

Earlier quoted context omitted.

I disagree, store UTC time and the name of timezone it was originally recorded in so it can be translated back to that as well. UTC only loses information.

Why not store it as a time date in the original timezone then?

You still need the timezone name to map back to UTC, in case you want to make some types of computations, usually along the lines of "how long ago was this" and "remaining time until this thing happens".

You may argue that we can use local time to make the computations and be done with it, but during DST transitions, local time jumps so the number of actual seconds won't be consistent.

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

#108

Post by nordiknomad5 »

dust42 wrote: post #87
nordiknomad5 wrote: post #80

I am not sure why my brave browser does not console out the error as in the OP console.log(new Date('2025/05/28').toDateString()); console.log(new Date('2025-05-28').toDateString()); console.log(new Date('2025-5-28').toDateString()); OutPut Below Wed May 28 2025 debugger eval code:1:9 Wed May 28 2025 debugger eval code:2:9 Wed May 28 2025 debugger eval code:4:9

If your local timezone is GMT>=0, then you wont see it. A special form of a Heisenbug that you only see easily when located in the Americas, while when in Europe/Africa/Asia it is invisible unless you switch your local time zone to any GMT-X value.

ok thanks for the clarification :)

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

#109

Post by ivan_gammel »

rubslopes wrote: post #97
names_are_hard wrote: post #90

Earlier quoted context omitted.

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…

All solutions have problems, but I think UTC midnight is simpler than dealing with mixed date formats in the backend.

It’s 2025 and major backend stacks have domain-specific time types like LocalDate etc. Using them is the only correct and actually the simplest solution.

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

#110

Post by dotancohen »

aloha2436 wrote: post #14
Y_Y wrote: post #10

Earlier quoted context omitted.

> That is not a better world. Not a better world, just the current world.

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.
Post reply on HN