> Even when working with dates on an ISO format, including the offset, the next time we want to display that date, we only know the number of milliseconds that have passed since the UNIX epoch and the offset. But this is still not enough to know the human moment and time zone in which the payment was made.
Can someone explain to me what this means? ISO date strings should capture that exact information. Sure, there are caveats to storing dates/times, but I find the idea that JavaScript (or any language) needs built-in constructs for this purpose to be questionable.
Beyond that, both Temporal and Date solve what should be very simple problems in very complicated ways. I've yet to run into a circumstance where ISO strings don't suffice.
Because the timestamp and offset (i.e., a numeric indication of the time zone, as a difference from UTC) aren't actually enough information to calculate the local time, pedantically.
Why not?
1. Leap seconds. They exist at irregularly spaced intervals based on the Earth's actual rotation, which is a) not perfectly consistent and b) ever so slightly, continuously, on average, slowing down. The offset would only allow you to figure this out, in principle, if you already had the UTC time - which has to be calculated from the timestamp in a complex way that accounts for leap second information retrieved from a database.
2. Time zones change over time. Some parts of the world use daylight savings time and others don't. It's possible in principle for a daylight savings time transition (which occurs on different dates in different parts of the world) to occur between two displays of the date, invalidating the offset.
3. Time zones change over (longer periods of) time. They've historically been created, removed or had their borders changed. Sir Sandford Fleming's system is now 148 years old (and there were others before it), and geopolitics happens.
4. Calendars. Maybe you don't care about, say, the eras of the Japanese calendar (https://en.wikipedia.org/wiki/Japanese_era_name), but some applications will require knowing about it. If you need to deal with history, then the conversion between Gregorian and Julian calendars will also depend on locale, because the Gregorian calendar was adopted at different points in different parts of the world.
Aren’t all of those example problems solved with a versioned database of timezones and calendar algorithms? Any past “universal” date can be converted to a fully defined local, contextual time based on such a resource. But, it doesn’t exist.
In theory it's a solvable problem. In practice most libraries handling date and time aren't living up to that expectation, in particular and core system libraries, because it's just hard and tradeoffs are made.
Such databases do exist, and they're how more heavyweight libraries solve the problem. But there has to be code that applies the algorithms; there has to be a reasonable guarantee that the code will actually be used in the appropriate situations; and dates need to encode the information about which database version to use (otherwise you will run into problems e.g. if you're trying to plan around future dates; "render the date according to the current rules for the current locale" isn't always correct, and "render the date according to the rules for the place and time when and where the object was created / data was stored" isn't either, and "render the date according to the rules for the place and time that it represents" isn't either).
tl;dr: dates are hard because they represent an intersection between adjusting a model to meet physical reality, with l10n/i18n concerns (even if you don't care about language translation). Both of those are hard enough individually already.
Let's say I'm sorting some information about an event occuring in Florida, USA next year. It will be on July 4th at 3:00pm. I store this as an ISO string: "2025-07-04T03:00:00Z-5".
Florida (and the USA as a whole) have been discussing getting rid of the daylight savings change on-and-off for several years.
If that law goes through in December of this year, the date I stored for my event will now be off by an hour because come July 2025 Florida will be on UTC offset -6, not -5.
On the other hand, if I store the date with a fully qualified tz database timezone like this: "2025-07-04 03:00:00 America/New_York" the time will continue to be displayed correctly because the tz database will be updated with the new offset information.
If the calendar application want to be really accurate in a couple of years it's probably best to ask the user for coordinates for the event. You never know if that spot in Florida will be part of America/New_York next year.
> You never know if that spot in Florida will be part of America/New_York next year.
The example really threw me; in the case where you assume that Florida stops observing DST, Florida is definitely not going to be part of America/New_York, so that example is guaranteed to have the same problem as the UTC timestamp.
You're highlighting an important edge case here: The TZ database only splits regions reactively, not proactively.
But an actual lat/long pair is often neither available, nor desirable to be stored for various reasons.
Now that you mention it, I think I've seen some web applications that had a list of cities much longer than what's present in the TZ database for calendar scheduling purposes, probably to accomodate for just that future edge case.
The very most difficult part of writing date and time handling code is interfacing with systems whose developer thought date and time handling was completely straightforward :P.
It's hard, but it's not that hard so long as all the data is there. The biggest difficulty is working out the right frame of reference to store timestamps with. That's mostly only a catastrophic problem for future events involving people, but (as others in the thread note) it's still potentially an issue for audit (and other) data too.
Knowing which time zone a meeting is supposed to be held in is especially important around time zone changes.
> but I find the idea that JavaScript (or any language) needs built-in constructs for this purpose to be questionable.
Either this, or every project starts with a 200kb date library import. In reality, I haven't met a single project that I don't need to deal with dates and timezone. And I almost always have a date.ts in my utils library because I don't want to import a giant date library either. But for real, developers shouldn't need to deal with this. These operations and constructs that every sites need should be build into the language itself.
> Either this, or every project starts with a 200kb date library import.
It's interesting you say this but then go on to explain that you roll your own date library. Doesn't that discredit the idea that the alternative for every project must be a 200kb date library? I agree that most projects work with dates and time zones in some way, but that doesn't mean we'd have to use moment.js in the absence of the Date API. There's plenty of incompetent developers that would still do as such in the current year, but then this becomes a whole different argument.
The 200kb is already an underestimate. If you search temporal date polyfill and check the js size. It's 200kb for 'single' language. Date is much more complex than you expect.
And even yourself don't use it. The library authors will. There will be someday that people take the existence of temporal date api for granted. And you have no choice but import the polyfill if you want to deal with old browsers.
If you want to display a time you have in UTC in the user's local timezone, what other choice do you have (unless there's a way you can ask them for their timezone, but I always find that incredibly annoying when traveling)?
I think the author is talking about how ISO dates typically get converted and stored as integers or normalized (to UTC) ISO strings. If a payment was made in a different timezone from the server, the timezone locale (e.g. America/Los_Angeles) also needs to be separately stored in the db in order to preserve the full human readable meaning of the original payment date.
If timezone offsets are separately stored (or the UTC normalized ISO strings), this still isn't sufficient to know which locale the offset is referring to since multiple locales use the same timezone offsets.
It gets even more complicated when different locales shift their timezone offsets throughout the year due to daylight savings.
Something built into the language that can do real date math that accounts for leap seconds, DST, and so on is unusual. Especially if it's handling details like saving the timestamped history of political decisions in various places to start/stop using DST. Maybe not earth-shattering since you can get it with a library elsewhere, but handy.
Can someone explain to me what this means? ISO date strings should capture that exact information. Sure, there are caveats to storing dates/times, but I find the idea that JavaScript (or any language) needs built-in constructs for this purpose to be questionable.
Beyond that, both Temporal and Date solve what should be very simple problems in very complicated ways. I've yet to run into a circumstance where ISO strings don't suffice.