| 4. Why is it `Temporal.ZonedDateTime` not `Temporal.DateTime`? This is a fun story. Originally there was no `Temporal.ZonedDateTime`, and the type now called `Temporal.PlainDateTime` was called `Temporal.DateTime`. When we added a Temporal type with a datetime + time zone (its placeholder name was LocalDateTime), we needed to figure out naming for the date+time types so that developers would pick the right one: if they knew the time zone then they should pick one, and if they didn't know the time zone then they should pick the other. The biggest danger was this: if the zoneless type had been named `Temporal.DateTime`, then developers new to JS would almost certainly use it because it sounds like it should be the default. This exposes programs to subtle time zone bugs that only manifest 2x per year when time zones switch from DST/"Summer Time" to standard time and back again. I'd seen my previous company take two years (!!!) and thousands of hours of developer time to fix exactly this bug because many years before that our 23-year-old founders didn't realize that `DATETIME` in SQL Server was a zoneless type that would skip or lose an hour twice per year. I was determined to reduce the chance of the same mistake with Temporal by ensuring that the zoneless type would not (like in SQL Server) look like the default type that everyone should use for date/time data. Naming is hard! My preference was to use "DateTime" for the zoned type, and an something obviously non-default like "ZonelessDateTime" for the other one. Other champions felt the opposite: that because we were adding a time zone then its name should be longer. Eventually we settled on "Plain*" for all zoneless types and "ZonedDateTime" for the DST-safe one. You can read 150 comments in https://github.com/tc39/proposal-temporal/issues/707 if you want to understand the arguments made on all sides of this issue. 5. Why is it `Temporal.Now.zonedDateTimeISO()` not `Temporal.Now.zonedDateTime()`? I tried. The presence of "ISO" in method names (of `Temporal.Now` and a few other Temporal methods) is my biggest regret in the 6 years I spent working on this proposal. That said, it could have been even worse. Here's some history. "ISO" in this context refers to the ISO 8601 calendar, as opposed to the Chinese calendar, the Hebrew Calendar, the Coptic calendar, the Persian calendar, one of several Islamic calendars, and of course the Gregorian calendar which is effectively the same as ISO 8601 except the former uses BC/AD eras. One of the features of Temporal is to support both Gregorian and non-Gregorian calendars. Most of the world's population uses a non-Gregorian calendar for some purposes, like determining holidays or for official government documents. So it's convenient that user can write code like this: // What's the date of the next Chinese new year?
Temporal.Now.zonedDateTimeISO()
.withCalendar('chinese')
.add({ years: 1 })
.with({ month: 1, day: 1})
.toPlainDate()
.withCalendar('gregory')
.toLocaleString()
// => '2/6/2027' In 10 years of working on Temporal, the argument that took more hours and frustration was whether we should default to the ISO calendar in Temporal APIs. One side of this argument was this: in localization, you never want a default locale because then developers won't write or test their code to work in other locales. For languages this is exactly the right approach because there is no default language worldwide that everyone knows. Therefore, we should not have a default calendar in Temporal. The other side of that argument was this: the Gregorian calendar is used in almost every country in the world for almost all use cases that software will need to handle. Exceptions prove the rule, because the most common use of non-Gregorian calendars in software is building apps that correlate Gregorian with another calendar so that multi-calendar users can see both dates side-by-side. Therefore, we should make era-less Gregorian (called the ISO 8601 calendar in JS) the default calendar in Temporal. After many hours of discussion, it was clear that neither side could convince the other. So we made a painful compromise: we'd have two variations of APIs. Methods like `Temporal.Now.zonedDateTimeISO()` would use the ISO 8601 calendar by default, and methods like `Temporal.Now.zonedDateTime()` would require the user to provide a calendar or would throw a `RangeError`. This compromise was not ideal because it would confuse developers who'd call the shorter ISO-less methods and end up with exceptions at runtime. In 2023 we had an opportunity to improve it somewhat, because Temporal had to trim about a third of the surface area of the the proposal (IIRC, about 100 properties and methods!) to address concerns from browser implementers about the RAM and download size impact of so much new code on devices like Apple Watch and low-end Android phones. As part of that trimming exercise, we decided to remove one of the ISO-default vs. calendar-required method pairs. Thankfully, the ISO-default variant was retained. I lobbied to remove "ISO" from the method names, now that differentiating them from their calendar-required counterparts was not required anymore. This lobbying didn't succeed. See https://github.com/tc39/proposal-temporal/issues/2846 for details. I'm not happy with the extra `ISO` that millions of developers and AI agents will have to be typing in the decades to come. But in the grand scheme of things this is a small price to pay for a dramatically improved date/time/timezone/calendar API. Building standards is inherently a team sport, and if you're winning every argument then it's probably an unhealthy team. Overall I'm quite happy where we ended up with Temporal, even if some of the decisions didn't match what I thought would be best. Anyway, I hope this background is useful context. |