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

71–80 of 167 posts

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

#71

Post by normie3000 »

jasode wrote: post #57
bandrami wrote: post #6

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

> on a language without a standard library? Because the other languages & with bigger runtimes and more comprehensive standard libraries such as Java applets, Microsoft Silverlight, Macromedia Flash that were promoted for browsers to create "rich fat clients" were ultimately rejected for various reasons. The plugins had performance problems, security problems, browser crashes, etc. Java applets was positioned by Sun…

> other languages & with bigger runtimes and more comprehensive standard libraries such as Java

Java's Date standard lib was awful for 2 decades, so there's no guarantee that a big standard library is a good standard library.

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

#72

Post by skissane »

Scarblac wrote: post #58
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.

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.

> and the name of timezone

The problem is that can be difficult to portably determine. One wishes POSIX had an API “give me IANA time zone name for current process” which would do the needful to work it out (read TZ environment variable, readlink /etc/localtime, whatever else might be necessary)… but no, you are left to do those steps yourself. And it works reasonably well if the TZ environment variable is set, but it most commonly isn’t; readlink of /etc/localtime works on macOS and some Linux distros… but others make /etc/localtime a regular file not a symlink, which makes it all a lot harder

And that’s POSIX. Then there’s Windows which is possibly the last platform to still use its own timezone database instead of IANA’s. Now, Unicode CLDR maintains a Windows-to-IANA mapping table… but you have to ship both that table, and maybe the IANA timezone DB too, with your app, and keep them updated

I really wish Microsoft would ship the IANA database with Windows, and the IANA-Windows mapping table too, and provide APIs to query them, and keep them updated with Windows update. The core Windows OS and existing Windows apps can keep on using the legacy Windows TZ database for backward compatibility, whereas portable apps could use IANA instead if they wish

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

#73

Post by shreddit »

shreddit wrote: post #43
thrdbndndn wrote: post #41

Earlier quoted context omitted.

How is slashes ambiguous if you use YYYY and in YMD order?

Because Americans use slashes commonly in Y/D/M

My apologies to all Americans, of course i meant M/D/Y, i just got it backwards

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

#74

Post by sethammons »

normie3000 wrote: post #71
jasode wrote: post #57

Earlier quoted context omitted.

> on a language without a standard library? Because the other languages & with bigger runtimes and more comprehensive standard libraries such as Java applets, Microsoft Silverlight, Macromedia Flash that were promoted for browsers to create "rich fat clients" were ultimately rejected for various reasons. The plugins had performance problems, security problems, browser crashes, etc. Java applets was positioned by Sun…

> other languages & with bigger runtimes and more comprehensive standard libraries such as Java Java's Date standard lib was awful for 2 decades, so there's no guarantee that a big standard library is a good standard library.

Even in a good standard library, oddities arise. Many praise Go for its standard library but then there is its time format that raises an eyebrow: 01/02 03:04:05PM '06 -0700

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

#75

Post by mariusor »

Scarblac wrote: post #58
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.

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?

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

#76

Post by augusto-moura »

bandrami wrote: post #6

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

What? JavaScript _has_ a standard library. And even though it has a lot of legacy baggage, it is very well defined [1] [2]. Much better defined than C, for example, where a lot of undefined behavior is given as common practice, but in reality is up to compiler implementation, and varies from architecture to architecture.

JavaScript even with all its thorns, it's a very consistent ecosystem nowadays, across browsers and architectures. Being forever retro-compatible is a good thing, meaning that most code that ran during the 2000s, can still be run with minimal change.

[1]: https://262.ecma-international.org/

[2]: https://www.w3.org/TR/

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

#77

Post by floydnoel »

torben-friis wrote: post #49
shreddit wrote: post #43

Earlier quoted context omitted.

Because Americans use slashes commonly in Y/D/M

Uh, TIL. As a non American it was known to me that Americans use the YDM format but I had no idea slashes vs dashes carried meaning for that.

they don’t really, at least not in any universal sense. in the military (marine corps) we always used YMD with slashes. i would say that in non-military contexts, dashes are seen with YMD more frequently. but dashes or slashes are used for both YMD and MDY and there's no legal rule or regulation nor requirement to use one or the other. some people just pattern match quickly and assume too much based on that.

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

#78

Post by n2h4 »

normie3000 wrote: post #71
jasode wrote: post #57

Earlier quoted context omitted.

> on a language without a standard library? Because the other languages & with bigger runtimes and more comprehensive standard libraries such as Java applets, Microsoft Silverlight, Macromedia Flash that were promoted for browsers to create "rich fat clients" were ultimately rejected for various reasons. The plugins had performance problems, security problems, browser crashes, etc. Java applets was positioned by Sun…

> other languages & with bigger runtimes and more comprehensive standard libraries such as Java Java's Date standard lib was awful for 2 decades, so there's no guarantee that a big standard library is a good standard library.

[dead]

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

#79

Post by account42 »

fnord123 wrote: post #22
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.

RFC3339. ISO 8601 allows for 2 or 6 digit years. Truncating to 2 is just incorrect, and 6 digits is absurd. And you can read the RFC without paying ISO - and you can discuss the RFC with people who have also read it instead of relying on people using the Wikipedia page to interpret and explain ISO 8601. I have a scheduling service at work and I keep getting requests for implementing ISO 8601 timestamps but I ignore t…

Plus RFC3339 allows you to use a space instead of the ugly T delimiter between the date and time.

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

#80

Post by nordiknomad5 »

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

Post reply on HN