This is a big milestone to getting Temporal shipped in Chrome (unflagged), which will have huge positive on JS developers around the world. Thank you all for your hard work to get this built and over the finish line.
Yep. That said, for end users it's a fairly good story because consumer OSs have gotten very good at automatically adjusting clients' time zone based on geo-location. Just like when you fly to another country and the first thing that happens when you connect your laptop to the internet is you're offered to change your time zone to the local time zone. I assume that the same thing happens when you're in a place whose IANA time zone changes like your America/Punta_Arenas case or many others like it.
> https://github.com/tc39/proposal-canonical-tz - appropriately to these comments, a proposal to handle tzdb changes, built on top of JS Temporal, includes some great examples of all the ways this can happen
Thanks! I was the co-champion of that proposal. Parts of it were merged into Temporal last year, and other parts are already part of the JS Internationalization (ECMA-402) specification here: https://tc39.es/ecma402/#sec-use-of-iana-time-zone-database
There's no geographic adjustment but at least there is some choice for users about which Islamic calendar variation should be used. For example, "islamic-rgsa" in JS is the Hijri calendar, Saudi Arabia sighting.
Temporal has built-in support for non-Gregorian calendars, including parsing, arithmetic, etc. so you can do things like this:
function chineseNewYears() {
const dt = Temporal.Now.plainDateISO().withCalendar('chinese');
const current = Temporal.PlainDate.from({year: dt.year, month: 1, day: 1, calendar: 'chinese'})
const next = current.add({years: 1})
return { current, next }
}
`The next Chinese New Year is ${chineseNewYears().next.withCalendar('gregory').toLocaleString('en-UK')}`
// => 'The next Chinese New Year is 17/02/2026'
Temporal includes `equals` methods on every type. String comparison sometimes works, but there are enough cases where it doesn't (especially when comparing strings that refer to the same data but were generated by different libraries so formatting is different for things like trailing zeroes of decimals, time zone aliases, etc.) that it's usually best to use a library function for comparison instead of just using string comparison.
