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

161–167 of 167 posts

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

#161

Post by ryao »

isleyaardvark wrote: post #104
ryao wrote: post #95

Earlier quoted context omitted.

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

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

I consider this to be a desirable behavior.

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

#162

Post by TZubiri »

fatata123 wrote: post #139
TZubiri wrote: post #2

[flagged]

Like genital herpes, I am stuck with it. I might as well learn to like it. And eventually convert others across to the cause.

Remember to disclose, I'm not a lawyer, but pretty sure it's criminal to spread without informing and getting consent.

Your employer needs to know before you infect their codebase with react.

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

#163

Post by globular-toast »

ryao wrote: post #160
IAmBroom wrote: post #142

Earlier quoted context omitted.

The question is clear. You are obfuscating it, for your own entertainment.

It is unclear to me. It has been ever since I was a child. This is what happens with periodicity. There is no 1 lunch reference point when you just say lunch in this sort of question.

You're not alone, believe me, but one of the things you have to learn at some point is that for the vast majority of the population the question is perfectly clear. This is an example of the midwit meme, something like this:

IQ 55: it happened before lunch,

IQ 100: "lunch" isn't a time, lunch for whom? And which lunch? Their first ever lunch? Do babies even have lunch?

IQ 145: it happened before lunch.

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

#164

Post by isleyaardvark »

ryao wrote: post #161
isleyaardvark wrote: post #104

Earlier quoted context omitted.

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

> 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. I consider this to be a desirable behavior.

For most cases I think that would be correct, but I will say if I am looking at my ATM withdrawals for a trip I made to San Francisco, I would like the time shown to be the SF time and not that of my local hometown, and vice versa if I'm in SF.

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

#165

Post by ryao »

globular-toast wrote: post #163
ryao wrote: post #160

Earlier quoted context omitted.

It is unclear to me. It has been ever since I was a child. This is what happens with periodicity. There is no 1 lunch reference point when you just say lunch in this sort of question.

You're not alone, believe me, but one of the things you have to learn at some point is that for the vast majority of the population the question is perfectly clear. This is an example of the midwit meme, something like this: IQ 55: it happened before lunch, IQ 100: "lunch" isn't a time, lunch for whom? And which lunch? Their first ever lunch? Do babies even have lunch? IQ 145: it happened before lunch.

Usually, people with higher IQs are the ones who have trouble with such things. There is a logical difference between “before lunch” and “before lunch that day”. This is similar to how higher IQ individuals see the Monty hall problem as having a 2/3 probability rather than a 1/2 probability in the famous version of the problem posed to Marilyn vos Savant. They are often derided as being idiots for not having “common sense”, even when their remarks are correct.

That said, IQ is considered obsolete given the theory of multiple intelligences. IQ only covers a subset of it.

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

#166

Post by hnbad »

meekaaku wrote: post #62
hnbad wrote: post #48

Earlier quoted context omitted.

It's documented undefined behavior, really. Implementations are allowed to accept other input than ISO strings and interpret them how they like. The real "bug" in the example is 2025/05/28 being May 28th because the implementation ignores timezones for that format. The issue with `Date` is that it is based on the original `java.util.Date` class and inherits all of its problems: https://docs.oracle.com/en/java/javase/…

how about postgres style timestamp and timestamptz unless a timezone/offset is given, its considered plain date/time, not an epoch.

`Temporal` has three main types for this:

- `Temporal.Instant` is a timestamp, the equivalent of a millisecond epoch timestamp or a UTC ISO string.

- `Temporal.PlainDateTime` (and `Temporal.PlainTime`, `Temporal.PlainDate`, `Temporal.PlainYearMonth` and `Temporal.PlainMonthDay`) is timezone-unaware (i.e. they don't represent an actual point in time unless qualified with a timezone, e.g. when you just want to reference a calendar date).

- `Temporal.ZonedDateTime` is timezone-aware (i.e. what you usually mean when dealing with specific instants in time).

There's also `Temporal.Duration` which represents a delta between two instants and can be used to perform date manipulation (e.g. adding exactly one day or year to a given instant).

I guess in terms of Postgress, `Temporal.ZonedDateTime` and `Temporal.PlainDateTime` are similar to `timestamptz` and `timestamp`, `Temporal.PlainDate` and `Temporal.PlainTime` are similar to `date` and `time` (without a timezone) and `Temporal.Duration` is similar to `interval`. It's odd that postgres allows for `time` to have a timezone but I guess that's only meant to be used when storing an instant as a set of `time` and `date` rather than a single `timestamptz`.

`Temporal.PlainYearMonth` and `Temporal.PlainMonthDay` seem like the odd ones out but they make as much sense as `Temporal.PlainDate` if you want to reference specific calendar dates/months with incomplete information. I guess for sake of completeness one could argue for a need to be able to specify a precision for `Temporal.Time` to distinguish between a reference to "8 am", exactly "8:00", exactly "8:00.0" and so on, but that use case seems a lot more niche than those solved by the additional date types.

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

#167

Post by jcul »

badmintonbaseba wrote: post #35
jcul wrote: post #30

Earlier quoted context omitted.

There's this handy venn diagram that I've seen floating around for a long time. Just found a random link to it with an image search: https://gyazo.com/d8517f72e24c38f055e17182842b991c/max_size/... ISO 8601 does have some strange formats...

That's a screenshot of this website: https://ijmacd.github.io/rfc3339-iso8601/

Thanks! That's where I remember it from.
Post reply on HN