FRESH

Hacker News

Home

Date is out, Temporal is in

463 points by alexanderameye

by tshaddox

9 subcomments

This article lists several of the absurdities of the Date constructor, but only barely touches on the most unforgivable one. The example from the article is:
```
  // Unless, of course, you separate the year, month, and date with hyphens.
  // Then it gets the _day_ wrong.
  console.log( new Date('2026-01-02') );
  // Result: Date Thu Jan 01 2026 19:00:00 GMT-0500 (Eastern Standard Time)
```
In this example, the day is "wrong" because the constructor input is being interpreted as midnight UTC on January 2nd, and at that instantaneous point in time, it is 7pm on January 1st in Eastern Standard Time (which is the author's local time zone).
What's actually happening here is a comedy of errors. JavaScript is interpreting that particular string format ("YYYY-MM-DD") as an ISO 8601 date-only form. ISO 8601 specifies that if no time zone designator is provided, the time is assumed to be in local time. The ES5 spec authors intended to match ISO 8601 behavior, but somehow accidentally changed this to 'The value of an absent time zone offset is “Z”' (UTC).
Years later, they had realized their mistakes, and attempted to correct it in ES2015. And you can probably predict what happened. When browsers shipped the correct behavior, they got too many reports about websites which were relying on the previous incorrect behavior. So it got completely rolled back, sacrificed to the altar of "web compatibility."
For more info, see the "Broken Parser" section towards the bottom of this article:
https://maggiepint.com/2017/04/11/fixing-javascript-date-web...

by procaryote

3 subcomments

There's a lot wrong with Javascript's Date, but the fact that it's an object is is not really in the top 10.
Would it have been nice if the Date object had been immutable? Sure, but the fact that changing the mutable object does indeed change the object shouldn't be a shock

by LegionMammal978

7 subcomments

I do find it annoying how the Temporal API, just like nearly all other datetime APIs, has 0 support for querying leap-second information in any shape or form. Suggested workarounds like temporal-tai all require plugging in a leap-second file and keeping it updated, which is especially painful for client-side JS, where you can't just download a leap-second file from someone else's site thanks to the SOP. Meanwhile, browsers update on a cadence more than sufficient to keep an up-to-date copy, but the datetime APIs refuse to expose leap-second info because they're too committed to "only UTC is in-scope for this project".
(The context is that I want to write some JS tools for astronomical calculations, but UTC conversions need leap-second info, so this trend makes it impossible to write something that Just Works™.)

by daveoc64

2 subcomments

I'm really surprised at how Temporal is only just rolling out in Chrome stable.
I would have hoped it'd be ready for wider use by now.
https://caniuse.com/temporal

by crabl

2 subcomments

we've been using this Temporal polyfill and it's been awesome so far: https://github.com/js-temporal/temporal-polyfill

by irjustin

3 subcomments

Late to the party, I really wish everyone would copy Rails + Ruby, but specifically it's Rails additions.
2 things it got right:
1. Like the article a great API - Time.current.in_time_zone('America/Los_Angeles') + 3.days - 4.months + 1.hour
2. Rails overloads Ruby's core library Time. You're in 1 object the whole time no swap/wondering.
In the py world, pendulum is close but just like the article, it's cumbersome as it's still a separate obj (i.e. Temporal vs Date) and so you need to "figure out" what you have to manipulate or need to cast it first.
Overloading the core libs is dangerous for a whole host of reasons but for the end developer it's a pleasure to use.
If we could just do `new Date().add({ days: 1})` it would be so easier.

by munificent

0 subcomment

> When an immutable value is assigned to a variable, the JavaScript engine creates a copy of that value and stores the copy in memory
Not exactly. The language doesn't specify whether the value is copied or not and, precisely because values are immutable, there's no way for a user to tell if it was or wasn't.
For example, strings are also immutable value types, but you can be certain that no JS engine is fully copying the entire string every time you assign one to a variable or pass it to a parameter.

by tensegrist

0 subcomment

typo:

    // A numeric string between 32 and 49 is assumed to be in the 2000s:
    console.log( new Date( "49" ) );
    // Result: Date Fri Jan 01 2049 00:00:00 GMT-0500 (Eastern Standard Time)

    // A numeric string between 33 and 99 is assumed to be in the 1900s:
    console.log( new Date( "99" ) );
    // Result: Date Fri Jan 01 1999 00:00:00 GMT-0500 (Eastern Standard Time)

the second interval should start at 50, not 33

by rjrjrjrj

1 subcomments

Good article, but “Java deprecated their Date way back in 1997” is not exactly true. They deprecated a lot of methods and constructors in JDK1.1 when Calendar was introduced, but the class itself was never deprecated and it was the preferred way to represent a point in time until the “modern” approach was provided in java.time in JDK8 (c2014)

by jackfranklyn

1 subcomments

The timezone handling alone makes Temporal worth the wait. I've lost count of how many bugs I've shipped because Date silently converts everything to local time when you least expect it.
The ZonedDateTime type is the real win here - finally a way to say "this is 3pm in New York" and have it stay 3pm in New York when you serialize and deserialize it. With Date you'd have to store the timezone separately and reconstruct it yourself, which everyone gets wrong eventually.
Only downside I can see is the learning curve. Date was bad but it was consistently bad in ways we all memorized. Temporal is better but also much larger - lots of types to choose between.

by xeckr

4 subcomments

I suspect that the arrival of ChatGPT caused traffic to the MDN Date API documentation to go down by at least half.

by Aardwolf

3 subcomments

Checking its API, I'm surprised that Temporal.Duration has a constructor with many parameters for years, months, days, ... all the way to nanoseconds, while Temporal.Instant has no way at all to create it given a current year/month/day, only from unix timestamp equivalents (or strings)
That seems to be functionality you'd want to have? Or is the intention you convert your numbers to string first and then back to a Temporal.Instant?

by ckocagil

1 subcomments

Late by a decade or more (JSR310 was released in 2014), but still a good development. I've tried convincing colleagues to use js-joda in the past but they thought they were keeping it simple by sticking to moment.js. They weren't.

by atoav

0 subcomment

If you ever find yourself in the situation where you have to decide whether 99 parses to year 1999 and what to do with 100 and where to draw the line between parsing the 90s and current years, you should probably pause, reath in andaout and take a long walk instead. And after you return you should scrap the whole thing and go back to the drawing board.
Implementing such a feature has not only no value, it has negative value. When you program libraries or interfaces you ahould think aboit how people will use it 95% of the time and mane that usecase as simple, predictable and free of potential footguns as possible. This is the opposite of that. It feels like something 15 year old me would have programmed after reading the first book on PHP and not something anybosy with any experience could have thought to be a good thing.

by Someone1234

3 subcomments

Except Temporal is not, in fact, out.
https://caniuse.com/temporal
The current global availability of native Temporal is 1.81%. For context, IE11(!) has a higher global usage than Temporal has native support. For my organization, this likely means we're years from being able to use Temporal in production, because getting the polyfills approved is such a hassle.
Keep in mind that even as of December last year, Chrome didn't ship with it yet (i.e. support is less than one month old). Safari still does not.

by schiffern

1 subcomments

```
  >It wholesale does not understand the concept of daylight savings time
```
While we're nitpicking (which I wholly support, by the way) it's "daylight saving time."
Cheers, great read.

by austin-cheney

1 subcomments

The article is super weird. It never mentions Date.now(). It dances around the subject and exhaustively mentions the equivalent convention for Temporal.
If you want Date to act like Temporal then only use Date.now() as your starting point. It generates the number of milliseconds since 1 Jan 1970. That means the starting output is a number type in integer form. It does not represent a static value, but rather the distance between now and some universal point in the past, a relationship. Yes, Temporal is a more friendly API, but the primary design goal is to represent time as a relational factor.
Then you can format the Date.now() number it into whatever other format you want.

by whiterook6

0 subcomment

So, hold on--the author's soul-breaking complaint isn't all of the "quirks" and inconsistencies with the Date functions, but rather the fact that it's an object? Specifically, an object with mutable properties in a language when all objects have mutable properties?
I mean, the author's conclusion is correct. But I disagree with the rationale. It's like hating an evil dictatorship because they use the wrong font in their propaganda.

by Yaggo

1 subcomments

The old JS Date API is far from perfect and I'm happy it being replaced, but part of the problem is various string-based formats and people being sloppy using them. Not to mention general complexity in time/date concept with timezones, summer time, leap seconds, etc.
For string format, just stick with ISO 8601. If you need to parse less-standard formats, use a robust library of your choise. The standard library should not try to support parsing zillion obscure formats. Outputting localized / human-readable format should be a responsibility of localization API anyway.
I also think that many libraries/APIs involving formatting things have some US centric design limitations, i.e. tendency to treat US formats as native and international support is often a bit after-thought. Especially with older stuff like the JS Date API.

by mastermedo

2 subcomments

I dislike the "Plain" prefix to the temporal objects, e.g. PlainDateTime. The prefix says nothing about the behavior of the class. Plain as opposed to what; ZonedDateTime. I would prefer "Local" over "Plain"; LocalDateTime.

by LoganDark

4 subcomments

Is Temporal even in though? Last I checked (last year or so), I had to use some bleeding edge version of Firefox to get it, and absolutely nothing else had it. I do agree though it's lovely, and I'd love to see native support for it.

by jrpelkonen

1 subcomments

Somewhat related: Jiff (https://github.com/BurntSushi/jiff) is a Rust library inspired by the Temporal api.

by lightningspirit

0 subcomment

If you do `new Date('2025-11-31T00:00:00Z')` you get `2025-12-01T00:00:00.000Z`, which is weird and potential cause for bugs when parsing date string from input. Right because of these inconsistency I created a small package backed as Regex to validate Date string input before throwing it on `new Date(stringDate)`.
https://www.npmjs.com/package/iso-8601-regex

by sublinear

2 subcomments

> My complaint is about more than parsing or syntax or “developer ergonomics” ... My problem with Date is that using it means deviating from the fundamental nature of time itself.
I don't really have a problem with the substance of this blog post. I have a problem with this exaggerated writing style. It means deviating from the fundamental purpose of writing itself!
I had to scroll all the way to the end to find the actual point, and it was underwhelming.
> Unlike Date, the methods we use to interact with a Temporal object result in new Temporal objects, rather than requiring us to use them in the context of a new instance
Bro, just be honest. This entire blog post was totally about developer ergonomics and that's okay. We all hate the way Date works in javascript.

by krzkaczor

0 subcomment

I hope that we can move to using DurationLike objects in place of ms (or sometimes seconds?) as plain numbers like in `setInterval`. `sleep({seconds 5})` is so much better than `sleep(5000)`.

by leeoniya

0 subcomment

related: i had to jump through the Date hoops recently (again) when rewriting uPlot's DST and timezone handling, but i'm pretty happy with the result that avoided much complexity, performance loss, and adding a dependency: https://github.com/leeoniya/uPlot/pull/1072
fun demos: https://leeoniya.github.io/uPlot/demos/timezones-dst.html

by recdnd

0 subcomment

Temporal feels less like a replacement for Date and more like an admission that Date was trying to represent too many different concepts at once.

by moralestapia

0 subcomment

Not yet, adoption is kind of poor atm.
This is not to detract from the quality of the article which is a top-notch introduction to this new API.

by nubskr

0 subcomment

Temporal being immutable alone is worth whatever migration pain we're about to endure.

by noduerme

0 subcomment

I use Moment.
And a few years later, I'm still using Moment.
And now I'm still using Moment.
And now...

by pmarreck

1 subcomments

I actually had no idea javascript Date was this bad until now.

by taf2

1 subcomments

If only Safari had support for Temporal... maybe next year...

by nchmy

2 subcomments

Anyone have links that indicate when Safari might have it?

by mastermage

0 subcomment

At one point we realy need to make web2. With a blank slate and maybe a much more sane implementation of Websites. Maybe just allow CSS Html and all functions need to run over Wasm. Wasm would need to get some more features for that but at least, you would avoid allot of bullshit.

by zvqcMMV6Zcr

1 subcomments

I am not sure if I like mixing value and formatting in single object. On other hand anything will be an improvement compared to that terrible old API.

by beeboop0

0 subcomment

[dead]

by jdonaldson

1 subcomments

[flagged]

by artursapek

0 subcomment

bro these ads I can't

by TZubiri

1 subcomments

Yes, you should use shiny new library instead of the glitchy javascript standard..
Unless you want your website to run in browsers older than a year
Maybe in 10 years we can start using the shiny new thing?