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

121–130 of 167 posts

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

#121

Post by dylan604 »

rf15 wrote: post #84
0points wrote: post #39

Earlier quoted context omitted.

As another swede, I dare you! We swedes use standardized ISO 8601 dates such as YYYY-MM-DD as dictated by our excellent government and you find it in use in our social security number, government correspondence and mostly everywhere.

> YYYY-MM-DD as dictated by our excellent government Same here in germany! ...Which is the reason why everyone ignores it in favour of the traditional format. I love democracy, and also mountain-shaped temporal unit ordering ^ It's 28.05.2025 13:15. Text-ordering by date is a nightmare because everything is first grouped by day-of-month, then month, then year! :)

So dates have endianness?

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

#122

Post by ezfe »

guffins wrote: post #119
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…

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 ther…

Simple answer is no, since your ID doesn’t have a time zone of birth on it, they have to read it as local time.

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

#123

Post by ezfe »

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…

Uh, no - meetings need to be stored with a timezone they were created in. This is how major calendar apps work.

In Apple Calendar you can enable advanced timezone settings and you get a timezone override option.

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

#124

Post by bandrami »

bandrami wrote: post #6

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

Since I'm here, one of my standard interview questions when I'm hiring is "how would you convert a Gregorian date to a Julian date?" (and I make clear there's no penalty for not knowing those terms, and explain them if needed.)

What I'm looking for is "there has to be a library function for that; I would look it up".

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

#125

Post by crubier »

bandrami wrote: post #6

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

An interesting related question could be: Why did all languages with standard libraries fail to become the lingua franca of the Web against JavaScript?

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

#127

Post by HPsquared »

crubier wrote: post #125
bandrami wrote: post #6

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

An interesting related question could be: Why did all languages with standard libraries fail to become the lingua franca of the Web against JavaScript?

Path dependence. JS was in the browser.

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

#128

Post by madcaptenor »

skissane wrote: post #70
shreddit wrote: post #43

Earlier quoted context omitted.

Because Americans use slashes commonly in Y/D/M

YDM is very rare; according to Wikipedia, only found in Kazakhstan, Latvia, Nepal, and Turkmenistan, and even in those countries it commonly coexists with other formats. I believe internationally that YMD and DMY are the two most common formats (and also the most logical), and the (much less logical) MDY comes third… YDM is a very distant fourth. MYD, DYM are theoretically possible but doubt anybody uses them Actuall…

I can't even see how someone could get to a format with the year in the middle. In uses where you don't need to specify the year you might use either MD or DM, and when adding the year you could put Y either on the front or back of either of those.

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

#129

Post by [deleted] »

ezfe wrote: post #123
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…

Uh, no - meetings need to be stored with a timezone they were created in. This is how major calendar apps work. In Apple Calendar you can enable advanced timezone settings and you get a timezone override option.

[deleted]

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

#130

Post by jfindley »

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…

The standard is... well, it IS indeed a standard, I guess you can't really argue that, but it's a very great deal more permissive than many people might hope or expect. https://ijmacd.github.io/rfc3339-iso8601/ is a wonderful illustration of some of the deeply silly time formats permitted by ISO 8601.
Post reply on HN