131–140 of 416 posts
I’ve used date libraries from several languages and they’re all pretty awkward, but Ruby seems to have a very elegant solution thanks to the fact that primitives are also objects, so for example you can write things like 1.minute.ago or 1.day.from.now, which really helps in quick code comprehension.
There are quite a few things marinating in the TC39 pot right now. This is one that I wish would ship sooner, rather than later. I do recognize that it takes dev effort (on the part of v8, JSC, and SpiderMonkey engineers) to get the major browsers to support any of these new features. So I truly appreciate all that folks are doing to move the ball forward. The impatient person in me is cheering, "now get Records and…
The one I want is pattern matching ( https://tc39.es/proposal-pattern-matching/ ), which is still at stage 1 so many years away, sadly.
Earlier quoted context omitted.
The issue is that if you have a timestamp (e.g., `2025-06-20T17:00:00+02:00`) and a time zone (e.g., `Europe/Paris`) and you go to serialize it, are you explicitly including the time zone in that serialization? And when you deserialize it, are you checking that the offset is still valid for that time zone at that time? Temporal fixes this by using RFC 9557[1], which includes the time zone in the serialized representa…
I get that it’s more correct, but it assumes that Europe/Paris is a constant representation of how to apply the timezone-specific stuff but that’s incorrect. For example, ‘2025-06-20T17:00:00+02[Europe/Dublin]’ is a very different time if it’s created today vs if it were created in 1760 [1]. That’s a very extreme example, but timezone rules change and dates created from before the change was announced would be interp…
That's part of why they are tied to a certain city -- time zone rules are unlikely to bisect a city, although if they did I guess they'd have to deprecate it as a timezone name and use something else! Not sure if this has ever happened.
All of this is kept track of in the IANA Time Zone database, and labels like `Europe/Paris` are from keys into that database, not arbitrary. https://www.iana.org/time-zones
Sometimes when jurisdictions do weird stuff like changing their rules for (say) when Daylight Savings starts with no notice (effective tomorrow!), the libraries can take a bit of time to catch up and be correct again (and have the new version be distributed to all users).
But keeping track of (say) that America/New York on March 25 2024 is UTC-4 but March 2025 1990 is UTC-5 hours (they changed when Daylight Savings started in between those years) is absolutely something current (eg OS) time libraries do.
As well as keeping track of the gregorian correction in (depending on country) October 1582 (skipping over 10 days in the calendar!), when calculating historical intervals. They really do this, already!
That's why you say "Europe/Paris" or "America/New York" instead of "UTC-5", to let the library figure out the rules for offsets at that location on the time specified.
I assume Temporal will do the same. JS environments are usually running on OS's that will already provide this service, the browser or other execution environment won't have to implement it from scratch. Although I think moment.js did it from scratch, and distributes a timezone database with moment.js packages.
Earlier quoted context omitted.
First JavaScript is unfortunately not just for web apps. It’s also for desktop apps. Say my normal work day is from 8-5 and I work in the Eastern time zone. I set my Slack DND to outside those hours. I hop on a plane and go somewhere on the west coast. The perfect case, Slack would notify me of the change and let me decide whether I wanted to adjust the DND to local time or keep it. There are two possible scenarios f…
> First JavaScript is unfortunately not just for web apps. It’s also for desktop apps. A bit of a tangent but I’d say server is bigger than desktop. Like it or not JS (or TS) is the only cross platform development language that’s feasible today if you want to use a single language stack. As much as I despise the JS ecosystem practices and haphazard tooling there is no point trying to put the genie back in the bottle.
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…
why does the polyfill have dependencies? And it's 200KB alone compared to 60KB of moment.
Earlier quoted context omitted.
Can you provide a concrete example? Ideally using Temporal to show where it's going wrong. Like, if you created `2025-06-20T17:00:00+02[Europe/Dublin]` (the instant) in 1760, then its civil representation would be different, to account for the rules in place at the time. And then if you went to deserialize it today, Temporal would reject it. You'd get an error, because the rules in place when the string was serialize…
I must be misunderstanding what you’re saying. How does Temporal know to reject something serialized from before a rule was changed when the creation time of the serialized representation isn’t encoded? You’re saying in 1760 [Europe/Dublin] would be a different string vs today? A more concrete example is normal time-zone rule changes - `2025-06-20T17:00:00+02[Europe/Dublin]` would represent different instants if Dubl…
The way this works is by looking at offsets. Think of a time zone as a function mapping between civil time and physical time. Or, another way to think about it is a mapping from a civil time to an offset (which may not exist for gaps or may not be unique for folds) and a mapping from physical time to an offset (of which there is a bijection). With RFC 9557, you encode both the offset and the time zone into the serialized representation. Consider a case when you encode an offset corresponding to DST, and then DST is abolished. Your tzdb is updated. Then you go to deserialize this datetime. Its offset no longer matches the rules. This can be detected and Temporal reports an error. This is all explained in the docs.
Note that DST is only an example here, because it's a common manifestation of how this error arises. But it can happen with any change in offset.
So if you're in 1760 and you write down a datetime in the future using the rules of that time (of which, I'm not even sure that's a sensible question to ask), then you'd have a particular offset encoded in that future datetime. Now fast forward to the future and the rules have changed and are no longer consistent with the offset encoded in the datetime. Thus, you get an error.
Here's another take on the idea that I wrote for Jiff: https://docs.rs/jiff/latest/jiff/tz/enum.OffsetConflict.html
Think of it like this. In an RFC 9557 timestamp, you have an offset and you have a time zone. Those two pieces of information may be inconsistent with one another. For example, `2025-01-30T17:00+10[US/Eastern]`. When that happens, you can report an error. That's pretty much it.
> then the meaning of the instant is different because now there’s 2 different `2025-06-20T17:00:00+02[Europe/Dublin]` and which one you get will depend on when you deserialize.
If the region adjusted their close back by 15 minutes, then the offset would change. As for `2025-06-20T17:00:00+02[Europe/Dublin]`, it can only feasibly have two different interpretations: you can either interpret it as the instant `2025-06-20T17:00:00+02`, or you can interpret it as the civil time `2025-06-20T17:00:00` in the time zone `Europe/Dublin`, ignoring the offset. Or you can reject it. Temporal supports all of these modes, and it will by default reject such strings when the offset and time zone are inconsistent.
(There's a fourth mode, "prefer offset," that I won't get into here... It's not usually used for deserialization/parsing.)
I get that the naming Temporal is used for avoiding conflicts with typical time objects like Moment, Datetime, etc. But isn't it a terrible name? At first glance I thought it was some kind of garbage collection control
From TFA: > When JavaScript was created in 1995, the Date object was copied from Java's early, flawed java.util.Date implementation. Java replaced this implementation in 1997, but JavaScript is stuck with the same API for almost 30 years, despite known problems. I'm not a JavaScript or web developer, and I was surprised by the above. Can anyone comment on why the language was stuck with an inadequate api for so long?…
> Java replaced this implementation in 1997 If that date's correct, they replaced it with another flawed implementation. The 'good' one came much later: https://jcp.org/en/jsr/detail?id=310 > What are the forces at work here? I feel like I'm always simultaneously engaged in about 5 HN threads at a time, advocating for some combination of immutability, type-safety, and/or no-nulls. It's basically all I do. By and larg…
I’ve used date libraries from several languages and they’re all pretty awkward, but Ruby seems to have a very elegant solution thanks to the fact that primitives are also objects, so for example you can write things like 1.minute.ago or 1.day.from.now, which really helps in quick code comprehension.
That would actually be ActiveSupport, which does many things and the pain of its absence is quickly felt in any non-Rails codebase :) https://rubygems.org/gems/activesupport