321–330 of 416 posts
It’s almost a shame, considering all the effort that went into Moment and Luxon, which will largely be superseded. Luxon especially is a joy to work with.
Earlier quoted context omitted.
Pattern matching (and expression based assignment, of which idk if there’s a proposal for or not) are two things that would really drive a ton of value.
It's going to end up looking a lot like C# [0][1]; these two/three (JS/TS, C#) languages have been converging for a while now. Now just waiting for C# to get official first party discriminated unions! [0] https://learn.microsoft.com/en-us/dotnet/csharp/language-ref... [1] https://timdeschryver.dev/blog/pattern-matching-examples-in-...
We would all benefit if JS was more like C# in my opinion.
I don't think it's safe to say, more direct comparison of JS's Temporal would be java.time[1], which was introduced in Java 1.8 in 2014.
[1]: https://docs.oracle.com/javase/8/docs/api/java/time/package-...
I really like the temporal proposal, except for one thing: they rely on reference equality in comparisons. On other words: Temporal.Instant.from('2020-01-01') != Temporal.Instant.from('2020-01-01') This isnt inherently bad, but it effectively removes the ability to use these objects as Map keys or collecting them in a Set. I know why that decision was made, I'm just sad that this wont be possible. Maybe there will be…
Earlier quoted context omitted.
> Otherwise you'll get a bug twice per year due to DST Those of us of a certain age learned long ago never to schedule cron (etc.) jobs in a production environment between 01:00 and 03:00 local time.
Are your production servers configured in something other than UTC, or is there a factor here I'm missing? I've never really seen a good reason for a live server not to be Z'd out
Will this finally have a proper datetime formatter, too?
Temporal is great. I've been using it for a while in production using a polyfill [1], and it solves all issues I've encountered with the old Date() API (which is a lot). It clearly takes inspiration from other high-quality time libraries such as chrono in Rust and Joda Time in Java and combines them into a nice API that's pretty comfortable to use. Yes, it is a bit more complex to handle since it separates time into…
> Otherwise you'll get a bug twice per year due to DST Those of us of a certain age learned long ago never to schedule cron (etc.) jobs in a production environment between 01:00 and 03:00 local time.
A couple of weeks after that, on the night of the time change, I went to a party and afterwards a friend of mine and I went back to my house and started jamming and messing around with synthesizers and so on. As it neared 2:00 am, he told me he'd best be heading home, because it was getting rather late. I told him not to worry and that we were about to travel back in time...which we did. Then we spent another hour hanging out until it was almost 2:00 am again and he left.
I don't ever recall actually witnessing this happening before, in the past, I've always awakened in the morning to find I needed to change the clock on the stove. I really recommend staying up for the time change, because this is a pretty magical time of year. If you don't like the hour you experienced between 1:00 am and 2:00 am, you have just one opportunity per year where guess what — you get a do-over! Or if you really loved it, guess what - you can relive it!
Umm..I am not sure how the Islamic/Hijri calendar gonna work. Tomorrow is the first Shabaan in Pakistan but it is still 30th Rajab in Saudia. How will JS figure this difference out?
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:
Temporal.PlainDate.from("2025-01-30").withCalendar('islamic-rgsa').month // => 8
Temporal.PlainDate.from("2025-01-30[u-ca=islamic-rgsa]').month // => 8
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'
More info about how calendars are used in Temporal is here: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Can someone who's been following this explain why they're designing a new API instead of merging one of the successful open source APIs into the standard?
Temporal API is far more consequential than what was attempted before. Their proposal for serializing timezones is about to become the de facto standard extension to ISO 8601 (date/time).