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

141–150 of 167 posts

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

#141

Post by fnord123 »

Y_Y wrote: post #37
fnord123 wrote: post #22

Earlier quoted context omitted.

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…

I believe two-digit years haven't been allowed for a while: > ISO 8601:2000 allowed truncation (by agreement), where leading components of a date or time are omitted. Notably, this allowed two-digit years to be used as well as the ambiguous formats YY-MM-DD and YYMMDD. This provision was removed in ISO 8601:2004. (That's from https://en.wikipedia.org/wiki/ISO_8601 - I don't have the standards handy, ironically.) Hone…

I believe you. But I haven't paid ISO for the pleasure of reading the actual spec so that passed me by.

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

#142

Post by IAmBroom »

ryao wrote: post #96
globular-toast wrote: post #51

Earlier quoted context omitted.

This is great until someone asks whether a particular event happened before or after lunch.

I always felt the answer to this question is both, since there is always yesterday and tomorrow as far as lunch is concerned, so everything by definition is both before and after lunch. Perhaps the question is ill formed and needs to ask if the time was before, during or after lunch, during the day of the timestamp while defining what during means. That would have a more normal answer.

The question is clear.

You are obfuscating it, for your own entertainment.

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

#143

Post by IAmBroom »

Y_Y wrote: post #44
VoidWhisperer wrote: post #28

Earlier quoted context omitted.

PHP?

Rather than spoil this tremendous piece of humour, I'll just give a rot13-encrypted version of the answer: Ratyvfu

That's hardly unique to Ratyvfu. Nyy languages do that.

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

#144

Post by IAmBroom »

dylan604 wrote: post #121
rf15 wrote: post #84

Earlier quoted context omitted.

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

And Americans use Middlianness. Middle-endianness?

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

#145

Post by atoav »

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.

And ifnyou're displaying it in the Ui give users a date format option where ISO is the choice.

I use ISO for everything and your software wrongly assuming I want a deranged lunatic date format based on some locale is not going to cut it.

Locale is ok as a first guess, but maybe allow users tho make that choice?

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

#146

Post by atoav »

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…

The answer is that no age related verification-problem in real world is so sensitive that a day plus or minus would make any difference. So they skip the entire clusterfuck of a problem of timezones by just ignoring them.

I grew up in a country where you could legally buy beer with 16 and and hard alcohol with 18. So if the answer to "when should someone be allowed to choose to drink alcohol" has a variance of multiple years between countries who cares about a day or two.

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

#147

Post by dylan604 »

IAmBroom wrote: post #144
dylan604 wrote: post #121

Earlier quoted context omitted.

So dates have endianness?

And Americans use Middlianness. Middle-endianness?

great, now i've just wandered off wondering if there's psychology studies on the affect of one's endianness on their mental health. like, does one's parent object not show enough affection towards the middle-endian child objects vs their big-endian child objects, or will the little-endian child objects always win affection?

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

#148

Post by saltcured »

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.

Or if you really want to be future proof, store the geolocation so you can try to figure out the jurisdiction for any changing regulations. Maybe they didn't change the date of the switch, but changed the timezone boundary on the map.

But, then I guess we might need to account for fractured societies and actually store some kind of organizational code for which belief system the event author adheres to? :-)

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

#149

Post by realaleris149 »

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…

> 6 digit years

Totally insufficient for capturing important future events like the dead of the sun.

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

#150

Post by dotancohen »

saltcured wrote: post #148
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.

Or if you really want to be future proof, store the geolocation so you can try to figure out the jurisdiction for any changing regulations. Maybe they didn't change the date of the switch, but changed the timezone boundary on the map. But, then I guess we might need to account for fractured societies and actually store some kind of organizational code for which belief system the event author adheres to? :-)

You jest, but there are three calendars in active daily use in close enough proximity to me that it is not unheard of for mistakes to happen. Especially in the evening, as not all calendars start the new day at the same hour!
Post reply on HN