▲ | geocar 4 days ago | |||||||||||||||||||||||||||||||||||||||||||
> a date with a calendar associated but no time or timezone (might be due to being implied but also might be irrelevant, like in birthdates). It might also be relevant: Ever ask an older Korean person their age? > Instant: a fixed point in time with no calendar or location. Think e.g. "the user logged in at X date and time" but valid across the world for any timezone or calendar system. This is what we usually use "Unix UTC timestamps" for. This is not a thing. Those are intervals to some Epoch, maybe taking into account leap-seconds and maybe not. They are not very useful except grossly over long ranges. > - ZonedDateTime: like an Instant but associated with a particular calendar and location. Think an Instant but rendered "real" into a calendar system and timezone so the user can see a meaningful time for them. Like when a user logged in at X date and time. They don't do this from no location, but from some location. > - PlainDate: already discussed. Think e.g. birthdates. And already wrong. > - PlainTime: think "run task every day at 6:30pm". Erm no. You can say 18:30 hours after midnight, or you can say when the calendar says 6:30pm, but these are different things. Imagine the poor fool who wants to run the task every day at "1:30am" and has it run twice on some days. Bars close in some parts of the world at 30h (30時) to mean 6am the following day. > - PlainDateTime: like an Instant but associated with a calendar system, but no timezone. Think e.g. what a user would insert in a datetime picker, where the timezone is implied instead of explicitly selected. No, like a string. > - PlainYearMonth: think e.g. "we'll run our reports during October 2025". Nonsense. Also a string. > - PlainMonthDay: think e.g. "my birthday is June 13". Your birthday might be on the 29th of January. You cannot do reasonable arithmetic with such things, so it might as well be a string like many of these others. > I like how Temporal[0] does this. I don't if you can't tell. This stuff is complicated and I'd like more people exploring it because I don't know The Right Answer™ either, but I know enough to know that every existing solution is wrong in some way that can cause real harm. | ||||||||||||||||||||||||||||||||||||||||||||
▲ | kaoD 4 days ago | parent [-] | |||||||||||||||||||||||||||||||||||||||||||
Just FYI you were downvoted with no explanation because you missed the point in all of these and you're using a smug and off-putting tone which makes it look like only care about "being right" and not finding what "is right". Also you obviously didn't bother reading the "important concepts" link ([3]). I was going to assume good faith and reply to each of your comments but it'd probably be a waste of time. As a summary: most of your concerns are wrong due to (1) confusing "timezones" with "location" or "internationalization" (2) confusing internal representations (like Epochs) with what these objects represent as described in the "important concepts" link and (3) just being completely wrong like saying you cannot do reasonable arithmetic with PlainMonthDay or even understand that not every relevant operation is arithmetic (good luck calling `.toPlainDate(2025)` with your string representation). | ||||||||||||||||||||||||||||||||||||||||||||
|