[HN Gopher] Temporal: A nine-year journey to fix time in JavaScript
___________________________________________________________________
Temporal: A nine-year journey to fix time in JavaScript
Author : robpalmer
Score : 433 points
Date : 2026-03-11 15:35 UTC (7 hours ago)
(HTM) web link (bloomberg.github.io)
(TXT) w3m dump (bloomberg.github.io)
| jon_kuperman wrote:
| What a journey!
| bnb wrote:
| Can't wait for it to land in the server-side runtimes, really the
| last thing preventing me from adopting it wholesale.
| apaprocki wrote:
| Node 26! Only a matter of time... :)
| CharlesW wrote:
| FWIW, I've been using it server-side via the js-temporal
| polyfill for some time, no issues.
| bnb wrote:
| ooh I'd not seen that yet, will have to take a look.
| WorldMaker wrote:
| Deno has had it behind the `--untable-temporal` flag for quite
| a few Minor versions now and the latest Minor update (because
| of TC-39's Stage 4 acceptance and V8 itself also marking the
| API as Stable) removed the requirement for the flag and it is
| out of the box.
| samwho wrote:
| Thanks for linking to my silly little quiz in the article! :)
| virgil_disgr4ce wrote:
| Pretty big fan of Temporal. Been using the polyfill for a while.
| Very nice to use a modern, extremely well thought-through API!
| normie3000 wrote:
| No mention of JodaTime?
| sharktheone wrote:
| Very happy for it finally being there!
| nekevss wrote:
| Super happy to see Temporal accepted!
|
| Congrats to all the champions who worked super hard on this for
| so long! It's been fun working on temporal_rs for the last couple
| years :)
| plucas wrote:
| Would have been interesting to connect back to Java's own journey
| to improve its time APIs, with Joda-Time leading into JSR 310,
| released with Java 8 in 2014. Immutable representations,
| instants, proper timezone support etc.
|
| Given that the article refers to the "radical proposal" to bring
| these features to JavaScript came in 2018, surely Java's own
| solutions had some influence?
| apaprocki wrote:
| I would characterize it more as Joda likely informed Moment.js,
| which better informed TC39 because it was within the JavaScript
| ecosystem. As we discussed in plenary today when achieving
| consensus, every programming language that implements or
| revamps its date time primitives has the benefit of all the
| prior art that exists at that instant. TC39 always casts a wide
| net to canvas what other ecosystems do, but isn't beholden to
| follow in their footsteps and achieves consensus on what is
| best for JavaScript. So my view is this more represents what
| the committee believes is the most complete implementation of
| such an API that an assembled group of JavaScript experts could
| design over 9 years and finalize in 2026.
| mrkeen wrote:
| Yep, JavaScript got the bad version from Java too!
|
| https://news.ycombinator.com/item?id=42816135
| zvqcMMV6Zcr wrote:
| > Safari (Partial Support in Technology Preview)
|
| Safari confirmed as IE Spiritual successor in 2020+.
| cubefox wrote:
| 2026 A.D., still no support for native date pickers in mobile
| Safari.
| CharlesW wrote:
| Safari for iOS got native date pickers in 2012, and desktop
| Safari got them in 2021.
| WorldMaker wrote:
| Slower to implement new features, but still implementing them,
| just makes it the new Firefox. IE's larger problem was how
| _popular_ it had been before it stopped implementing new
| features. It was like if Google got bored with Chrome and
| decided to stop all funding on it. People would be stuck on
| Chrome for years after that investment stopped because of all
| the Chrome-specific things built around it (Electron,
| Puppeteer, Selenium, etc and so forth).
|
| Right now the world needs a lot more Safari and Firefox users
| complaining about Chrome-only sites and tools than it does
| people complaining about Safari "holding the web back".
| Safari's problems are temporary. Chrome is the new Emperor and
| IE wasn't bad because it stopped, it was bad because it stopped
| after being the Emperor for some time. People remember how bad
| the time was after the Empire crumbled, but it's how IE took so
| many other things down with it that it is easier to remember
| the interregnum after IE crumbled than to remember the heyday
| when "IE-only websites are good enough for business" sounded
| like a good idea and not a cautionary tale.
| nchmy wrote:
| > Right now the world needs a lot more Safari and Firefox
| users complaining about Chrome-only sites and tools than it
| does people complaining about Safari "holding the web back".
|
| There wouldn't be Chrome-only sites and tools if Safari
| wasn't holding the web back (no "quotes" needed, as that's
| precisely what they're doing).
|
| > Safari's problems are temporary.
|
| What are you talking about? They've been woefully behind for
| like a decade. Here's an excellent article on the topic:
| https://infrequently.org/2023/02/safari-16-4-is-an-
| admission...
|
| And an entire series:
| https://infrequently.org/series/browser-choice-must-matter/
| WorldMaker wrote:
| > There wouldn't be Chrome-only sites and tools if Safari
| wasn't holding the web back (no "quotes" needed, as that's
| precisely what they're doing).
|
| It's a matter of perspective. The safer perspective is:
| Safari isn't holding the web back, Chrome is moving too
| fast. Developers making Chrome-only sites and tools are
| moving too fast for the safety of web standards/web
| platform. Where one of the safety factors is "widely
| available in multiple implementations, not just a single
| browser".
|
| > > Safari's problems are temporary.
|
| > What are you talking about?
|
| The point is that Safari may be moving slow, but it is
| still moving. It doesn't have enough users to hold the web
| back. It isn't "always a decade behind", it 's "a couple
| years to a couple months behind", depending on which
| caniuse or MDN Baseline approach you want to take.
|
| There are some things Safari doesn't want to implement, but
| has registered safety or privacy or coupling reasons behind
| such things. Firefox is doing the same.
|
| Safari isn't trapping website developers in "old standards
| forever", it is encouraging developers to use safe,
| private, _stable_ choices. Chrome is "move fast and
| sometimes break things". Safari doesn't want to be that.
| That's _useful_ for the web as a platform to have one or
| two browsers considering their implementations. It 's a
| good reason to point out "Chrome-only" developers as being
| "too bleeding edge" (sometimes emphasis on the bleeding)
| and out of touch with standards and standards processes.
| redbell wrote:
| Oh, for a second, TeMPOraL
| (https://news.ycombinator.com/user?id=TeMPOraL) came to my mind!
| ChrisArchitect wrote:
| A good article and discussion from January:
|
| _Date is out, Temporal is in_
|
| https://news.ycombinator.com/item?id=46589658
| ChrisArchitect wrote:
| Aside: _Bloomberg_ JS blog? ok.
| deepsun wrote:
| Bloomberg has a pretty large software engineering department,
| including a lot of offshore contractors. Similar to Walmart
| Labs that does cool stuff as well, despite being part of a
| retail chain (retail industry typically sees SWEs a cost, not
| asset).
| ChrisArchitect wrote:
| oh, just meant it was a _new_ tech blog from them.
| jon_kuperman wrote:
| Yes! Brand new!
| wiseowise wrote:
| What surprises you? Terminal UI is written in JS using
| Chromium. It's not just plain Chromium, but it's still funny
| that it's pretty much same approach as universally (according
| to HN and Reddit) hated Electron.
|
| https://youtu.be/uqehwCWKVVw?is=wBijGwdD2k2jIOu7
| robpalmer wrote:
| Yep. You can learn more about why we created this new blog
| here: https://bloomberg.github.io/js-
| blog/post/intro/
|
| I hope you like it ;-)
|
| And if it seems like a surprise, you can blame me for not
| publicising this kind of content earlier given how long we've
| been working in this area. Thankfully Jon Kuperman and Thomas
| Chetwin (plus others) found the time and energy to put this
| platform together.
| philipallstar wrote:
| > have to agree on what "now" means, even when governments change
| DST rules with very little notice.
|
| I didn't spot how Temporal fixes this. What happens when "now"
| changes? Does the library get updated and pushed out rapidly via
| browsers?
| nekevss wrote:
| Typically time zone data is updated in IANA's time zone
| database. That data would need to be updated in the
| implementation. In this case, the browser would need to update
| their time zone data.
| WorldMaker wrote:
| Right, browsers own it instead of websites needing to rebuild
| Moment.js bundles. Additionally, most browsers pass the
| ownership further to the user's OS as the IANA timezone
| database is a useful system-level service and best updated at
| the cadence of OS "required" updates.
| apaprocki wrote:
| Depending on the situation, the data lives either within the
| browser or within the OS. Chrome releases ship versions of
| tzdata that correspond to the version of tzdata shipped with
| the ICU it uses, and they do backport updates to prior Chrome
| releases within a certain window. Apple has a sideband way of
| deploying tzdata to all devices that doesn't appear via the
| normal Software Update mechanism. So it all depends on which
| particular OS/browser combo you're interested in and the
| decisions those owners made.
| VanCoding wrote:
| A big step in the right direction, but I still don't like the
| API, here's why: Especially in JavaScript where I often share a
| lot of code between the client and the server and therefore also
| transfer data between them, I like to strictly separate data from
| logic. What i mean by this is that all my data is plain JSON and
| no class instances or objects that have function properties, so
| that I can serialize/deserialize it easily.
|
| This is not the case for Temporal objects. Also, the temporal
| objects have functions on them, which, granted, makes it
| convenient to use, but a pain to pass it over the wire.
|
| I'd clearly prefer a set of pure functions, into which I can pass
| data-only temporal objects, quite a bit like date-fns did it.
| qcoret wrote:
| All Temporal objects are easily (de)serializable, though.
| `.toString` and `Temporal.from` work great.
| VanCoding wrote:
| That's not what I mean. Even though it is serializable, it's
| still not the same when you serialize/deserialize it.
|
| For example `JSON.parse(JSON.stringify(Temporal.PlainYearMont
| h.from({year:2026,month:1}))).subtract({ years: 1})` won't
| work, because it misses the prototype and is no longer an
| instance of Temporal.PlainYearMonth.
|
| This is problematic if you use tRPC for example.
| gowld wrote:
| Would a plain data object be an instance of PlainYearMonth?
|
| If not, that regardless of being plain data or a serialized
| object with functions, you'd still need to convert it to
| the type you want.
| flyingmeteor wrote:
| You would need to use the `reviver` parameter of
| `JSON.parse()` to revive your date strings to Temporal
| objects. As others have said, it's a simple
| `Temporal.from()`
|
| https://developer.mozilla.org/en-
| US/docs/Web/JavaScript/Refe...
| cyral wrote:
| I've been doing this for so long and never knew there was
| a reviver param, thanks - that is super useful.
| Bratmon wrote:
| Having to provide a complete schema of your json
| everywhere your json gets parsed negates the advantages
| of json.
| true_religion wrote:
| The main advantage of json is that it's human readable
| and writable. Beyond that, it has no notion of user
| created data types so anyone using it has to do custom
| unmarshalling to get a type apart from sting, number,
| dict and list.
| hueho wrote:
| Most JSON libraries in typed languages require this for
| data binding to complex types though.
| rimunroe wrote:
| > For example `JSON.parse(JSON.stringify(Temporal.PlainYear
| Month.from({year:2026,month:1}))).subtract({ years: 1})`
| won't work, because it misses the prototype and is no
| longer an instance of Temporal.PlainYearMonth.
|
| I don't know if I'm missing something, but that's exactly
| how I'd expect it to compose. Does the following do what
| you wanted your snippet to do? Temporal.Pla
| inYearMonth.from(JSON.parse(JSON.stringify(Temporal.PlainYe
| arMonth.from({year:2026,month:1}))))
|
| JSON.stringify and JSON.parse should not be viewed as
| strict inverses of each other.
| `JSON.parse(JSON.stringify(x)) = x` is only true for a for
| a small category of values. That category is even smaller
| if parsing is happening in a different place than
| stringification because JSON doesn't specify runtime
| characteristics. This can lead to things like JSON parsing
| incorrect in JS because they're too large for JS to
| represent as a number.
| tshaddox wrote:
| This is also true of JavaScript Date instances, so I'm
| curious what solution you had that _did_ work with raw JSON
| stringify and parse.
| perfmode wrote:
| This is a real pain point and I run into the same tension in
| systems where data crosses serialization boundaries constantly.
| The prototype-stripping problem you're describing with
| JSON.parse/stringify is a specific case of a more general
| issue: rich domain objects don't survive wire transfer without
| a reconstitution step.
|
| That said, I think the Temporal team made the right call here.
| Date-time logic is one of those domains where the "bag of data
| plus free functions" approach leads to subtle bugs because
| callers forget to pass the right context (calendar system,
| timezone) to the right function. Binding the operations to the
| object means the type system can enforce that a PlainDate never
| accidentally gets treated as a ZonedDateTime. date-fns is great
| but it can't give you that.
|
| The serialization issue is solvable at the boundary. If you're
| using tRPC or similar, a thin transform layer that calls
| Temporal.Whatever.from() on the way in and .toString() on the
| way out is pretty minimal overhead. Same pattern people use
| with Decimal types or any value object that doesn't roundtrip
| through JSON natively. Annoying, sure, but the alternative is
| giving up the type safety that makes the API worth having in
| the first place.
| VanCoding wrote:
| It's not that much about type safety. Since TypeScript uses
| duck typing, a DateTime could not be used as a ZonedDateTime
| because it'd lack the "timezone" property. The other way
| around, though, it would work. But I wouldn't even mind that,
| honestly.
|
| The real drawback of the functional approach is UX, because
| it's harder to code and you don't get nice auto-complete.
|
| But I'd easily pay that price.
| TimTheTinker wrote:
| Sounds like we need an extended JSON with the express intent
| of conveying common extended values and rich objects:
| DateTime instants (with calendar system & timezone), Decimal,
| BigInt, etc.
| sheept wrote:
| I disagree: this is not unlike including the schema in the
| JSON itself. This should be handled by the apps themselves,
| since they would have to know what the keys mean
| regardless.
|
| If you do want the interchange format to be the one
| deserializing into specific runtime data structures, use
| YAML. YAML's tag syntax allows you to run arbitrary code
| inside YAML, which can be used for what you want.
| TimTheTinker wrote:
| I'm not talking about something arbitrarily extensible.
| Just a few more common data types -- primitive-like
| values that frequently need to be passed around.
|
| I'm not talking about compound values like x+y or
| lat/lon.
|
| This would probably best exist as a well-known wrapper
| around JSON itself.
| chrisweekly wrote:
| It should still be possible to continue using date-fns (or a
| similar lib) to suit your preference, right?
| VanCoding wrote:
| yes, sure. probably there will even pop up a functional
| wrapper around the temporal API occasionally. But would've
| been nice if it was like this from the start.
| causal wrote:
| I'm with you on this. I worked on a big Temporal project
| briefly and I was really turned off by how much of the codebase
| was just rote mapping properties from one layer to the next.
| Avamander wrote:
| > Especially in JavaScript where I often share a lot of code
| between the client and the server and therefore also transfer
| data between them, I like to strictly separate data from logic
|
| Which makes me wonder how it'll look like when interfacing with
| WASM. Better than Date?
| jayflux wrote:
| This was an intentional design decision. We wanted to make sure
| all the temporal types could be serialize/deserializable, but
| as you mentioned, you couldn't implicitly go back to the object
| you started with as JSON.parse doesn't support that.
|
| Instead the onus is on the developer to re-create the correct
| object they need on the other side. I don't believe this is
| problematic because if you know you're sending a Date,
| DateTime, MonthDay, YearMonth type from one side, then you know
| what type to rebuild from the ISO string on the other. Having
| it be automatic could be an issue if you receive unexpected
| values and are now dealing with the wrong types.
|
| There is an example here in the docs of a reviver being used
| for Temporal.Instant https://tc39.es/proposal-
| temporal/docs/instant.html#toJSON
| TimTheTinker wrote:
| Updating JSON.parse() to automatically create Temporal objects
| (from what shape of JSON value?) without a custom reviver would
| be a step too far, in my opinion.
|
| This is effectively no different from Date:
| serialize: date.toJSON() deserialize: new Date(jsonDate)
|
| in Temporal: serialize: instant.toJSON()
| deserialize: Temporal.Instant.from(jsonDate)
| tshaddox wrote:
| Don't JavaScript Date instances have the same problem? Date
| implements toJSON, but when parsing JSON you'll have to
| manually identify which string values represent Dates and
| convert them back to Date instances. The exact same is true of
| Temporal (e.g. Instant).
|
| And as far as I know, date-fns deals with native Date
| instances, not "data-only objects."
| hungryhobbit wrote:
| From the article: const now = new Date();
|
| The Temporal equivalent is: const now =
| Temporal.Now.zonedDateTimeISO();
|
| Dear god, that's so much uglier!
|
| I mean, I guess it's two steps forward and one step back ... but
| couldn't they have come up with something that was _just_ two
| steps forward, and none back ... instead of making us write this
| nightmare all over the place?
|
| Why not? const now = DateTime();
| sourcegrift wrote:
| If you give me your background I'll explain in longer terms but
| in short it's about making the intent clear and anyone who
| understands s modicum of PL theory understands why what's a
| constant is so and what's a function is so.
| themafia wrote:
| I'm a programmer. I'm a human. Perhaps we should also allow
| for some "human theory" inside our understanding.
| Bratmon wrote:
| I'm excited for this conversation. If you see someone respond
| to a developer ergonomics complaint with "If you give me your
| background I'll explain in longer terms... anyone who
| understands s modicum of PL theory" you're about to see some
| legendary bullshit.
|
| It's like witnessing a meteor shower!
| evolve2k wrote:
| Firstly, I really want this also and am supportive of an
| opinionated decision to put something at say
| Temporal.DateTime() that would be logical for developers to use
| 'most of the time'.
|
| However my guess is that the spec designers saw this lack of
| specivity as part of the problem.
|
| A key issue of dates and times is that we use them culturally
| in day to day use in very imprecise ways and much is inferred
| from the context of use.
|
| The concepts of zoned time and "wall clock" time are
| irreducable and it's likely much code will be improved by
| forcing the developer to be explicit with the form of time they
| want to use and need for their particular use case.
|
| I think this is why it's so explicitly specified right now.
|
| But I agree; I've often struggled with how verbose js can be.
|
| Maybe with time (pun intended), more syntactic sugar and
| shorter conventions can be added to expand what has been an
| incredible effort to fix deep rooted issues.
| sheept wrote:
| I think that it's nice it's explicit that the method returns
| the current instant, rather than some other zero value.
|
| There's also other methods that return other types, like
| const now = Temporal.Now.instant()
|
| which isn't as bad.
|
| One could argue that the ugliness of the API intentionally
| reveals the ugliness of datetime. It forces you to really think
| about what you mean when you want "the current date time,"
| which I think is one of the goals of the API.
| Bratmon wrote:
| What would have been wrong with Temporal.now() returning a
| sensible value?
| tmpfile wrote:
| Or const now = new Temporal();
| tshaddox wrote:
| That's uglier because, if you were previously doing new Date(),
| you almost certainly don't want a zonedDateTime. You almost
| certainly want an Instant.
| darepublic wrote:
| My playbook for JavaScript dates is.. store in UTC.. exchange
| only in UTC.. convert to locale date time only in the
| presentation logic. This has worked well for me enough that Im
| skeptical of needing anything else
| lpa22 wrote:
| Same here, this is the way
| NooneAtAll3 wrote:
| why UTC and not epoch then?
| SoftTalker wrote:
| Epoch (a/k/a "unix timestamps") are OK when you just need an
| incrementing relative time. When you start converting them
| back and forth to real calendar dates, times, with time
| zones, DST, leap seconds, etc. the dragons start to emerge.
|
| A lesson I learned pretty early on is always use the date-
| time datatypes and libraries your language or platform gives
| you. Think very carefully before you roll your own with
| integer timestamps.
| andrewl-hn wrote:
| The only time you need local dates is for scheduling. Stuff
| like "Report KPIs for each shift. Shifts start at 8:00 local
| time.", or "send this report every day at 10:00 local time", or
| "this recurring meeting was created by user X while they were
| in TimeZone Z, make sure meetings follow DST".
|
| Outside of scheduling UTC is the way.
| masfuerte wrote:
| > Report KPIs for each shift. Shifts start at 8:00 local
| time.
|
| To represent this you probably don't want a local date. Plain
| times [1] and plain date/times [2] are a better fit.
|
| [1]: https://developer.mozilla.org/en-
| US/docs/Web/JavaScript/Refe...
|
| [2]: https://developer.mozilla.org/en-
| US/docs/Web/JavaScript/Refe...
| 1-more wrote:
| The pathological case with scheduling is: It's 2015. You live
| in NYC. Your pal in Santiago, Chile says "hey next time
| you're here let's hang out." You say "great, I have a
| business trip there next April. Let's have dinner at 7pm on
| the 15th." They agree. You enter it into your calendar. If
| you store it as UTC, you're going to show up to dinner at the
| wrong time--the DST rules changed in between when you talked
| and when you expected dinner to happen. If you'd stored it as
| a local time with tzdb name America/Santiago you'd be there
| at the correct local time.
| themafia wrote:
| I have a scheduling system that allows users to specify
| recurring events. "Every Monday at 2pm." Which needs to be
| understood in the native timezone of that user and needs to be
| capable of being displayed in that timezone for all viewers or
| optionally in the native timezone of the viewing user.
|
| Temporal is a blessing.
| ibejoeb wrote:
| For recording instantaneous events, that's usually sufficient.
| It's often not enough for scheduling. You can always present
| UTC or any other zone relative to some other zone, but you need
| to know that zone. Maybe you're going to a conference in
| another region and you want to know the time of a talk in that
| zone because that's more important than your zone. You either
| need to couple the zone with the time itself, or you need to
| refer to it. There are good reasons either way. Having an
| atomic time+zone type is basically trading space for time. When
| its embedded, you can just use it, which can be better than
| assuming UTC and then looking up the zone based on, say, the
| location of the venue.
| recursive wrote:
| It does work quite well. Sometimes you need a time zone to go
| with it. It might not be common, but sometimes you need to know
| the local time _in a particular zone_ , which is not
| necessarily where the user is. I work on software that works
| with local times in arbitrary time zones. We submit data in a
| schema over which we have no control, which must include such
| local times that may or may not be in the time zone of the
| server or the current client machine.
| WorldMaker wrote:
| Storing in UTC is lossy. You've lost information about the
| event's original UTC offset, at the very least, and probably
| also its original time zone. Most backends today have good ways
| to round-trip offset information, and still compare dates
| easily (as if they were normalized to UTC). Some backends can
| even round-trip timezone information in addition to offsets.
|
| It's easy not to feel that loss as a big deal, but captured
| offsets can be very helpful for exactly debugging things like
| "what time did this user think this was?" versus time zone math
| (and DST lookups) from UTC. It can help debug cases where the
| user's own machine had missed a DST jump or was briefly on a
| different calendar or was traveling.
|
| But a lot of the biggest gains in Temporal are the "Plain"
| family for "wall clock times"/"wall calendar dates" and
| breaking them apart as very separate data types. Does a UTC
| timestamp of "2026-02-01 00:00:00Z" mean midnight specifically
| and exactly or where you trying to mark "2026-02-01" without a
| time or timezone. Similarly I've seen data like "0001-01-01
| 12:10:00Z" mean "12:10" on a clock without the date or timezone
| being meaningful, but Temporal has a PlainTime for that. You
| can convert a PlainDate + a PlainTime + a Time Zone to build a
| ZonedDateTime, but that becomes an explicit process that
| directly explains what you are trying to do, versus
| accidentally casting a `Date` intended to be just a wall-clock
| time and getting a garbage wall-clock date.
| tshaddox wrote:
| That generally works for timestamps (Temporal Instant). But it
| doesn't work for representing calendar dates with no time
| information (Temporal PlainDate) unless you add an additional
| strict convention like "calendar dates are always represented
| as midnight UTC").
| kemayo wrote:
| > Developers would often write helper functions that accidently
| mutated the original Date object in place when they intended to
| return a new one
|
| It's weird that they picked example code that is extremely _non_
| -accidentally doing this.
| wpollock wrote:
| > "It was a straight port by Ken Smith (the only code in "Mocha"
| I didn't write) of Java's Date code from Java to C."
|
| This is funny to me; Java's util.Date was almost certainly a port
| of C's time.h API!
| NooneAtAll3 wrote:
| so Temporal is copying cpp's std::chrono?
| andrewl-hn wrote:
| More like a copy of Java's JSR310, which in turn took many
| years to get right.
| SoftTalker wrote:
| It's been a while since I worked in JS but dealing with
| dates/times, and the lack of real integer types were always two
| things that frustrated me.
| xp84 wrote:
| They travelled through time (forward, at 1X) by _nine years_ to
| do this for us. I appreciate it.
| johncomposed wrote:
| As a side note, huge fan of Promise.allSettled. When that dropped
| it cleaned up so much of the code I was writing at the time.
| tracker1 wrote:
| Looking at the caniuse results... f*king Safari (and Opera)...
|
| https://caniuse.com/temporal
| agos wrote:
| I usually am not too harsh on Safari on implementation of new
| features but this is a bummer, and reflects poorly on them
| beezlewax wrote:
| And I have to support safari while dealing with all the
| problems that are mentioned in this article. Maybe there is a
| polyfill.
| the__alchemist wrote:
| Maybe I will be able to move away from my custom/minimal DT lib,
| and ISO-8601 timestamp strings in UTC. JS datetime handling in
| both Date and Moment are disasters. Rust's Chrono is great.
| Python's builtin has things I don't like, but is useable. Date
| and Moment are traps. One of their biggest mistakes is not having
| dedicated Date and Time types; the accepted reason is "Dates and
| times don't exist on their own", which is bizarre. So, it's canon
| to use a datetime (e.g. JS "Date") with 00:00 time, which leads
| to subtle errors.
|
| From the link, we can see Temporal does have separate
| Date/Time/Datetime types. ("PlainDate" etc)
| apaprocki wrote:
| Yes, please try! One of the main motivations for doing all this
| work is to slim down both the amount of code that has to be
| delivered and executed by providing everything that's needed by
| the platform. In addition, you're slimming the potential
| bug/attack surface as well, which is always nice.
| julius_eth_dev wrote:
| Nine years is a long time, but honestly it tracks with how deeply
| broken Date has been since Brendan Eich cargo-culted
| java.util.Date in 1995. The real win with Temporal isn't just
| immutability or timezone support -- it's that PlainDate and
| ZonedDateTime finally give us types that match how humans
| actually think about time. I've lost count of how many bugs I've
| shipped because Date silently coerces everything to UTC instants
| when half the time what you actually have is a "wall clock" value
| with no timezone attached.
| cityofdelusion wrote:
| Assuming this isn't an LLM bot, I don't see how you ship that
| bug multiple times. The docs for JS time are pretty minimal and
| it's clear it only stores UTC epoch, so why would you assume it
| can handle "wall clock time" with no other context?
|
| It doesn't matter if it's python or tsql or JS or perl -- you
| read the docs on the date time impl every time.
| SchemaLoad wrote:
| They do seem to be an LLM bot from comment history
| tshaddox wrote:
| Good luck making sure no one ever uses a "yyyy-mm-dd" string
| to represent a calendar date in a JSON API, then passes the
| value to the Date constructor, then formats that Date in a
| browser. It's an extremely easy mistake to make without very
| strict conventions around how calendar dates and timestamps
| are represented across the entire stack.
| wesselbindt wrote:
| > Assuming this isn't an LLM bot, I don't see how you ship
| that bug multiple times
|
| I don't know about the guy you're replying to, but I've made
| many mistakes in my coding life, and some of them more than
| once. The Date API is written in a way to obfuscate the real
| complexities of date and time management, so I find it quite
| easy to imagine someone stepping in the same footgun more
| than once.
|
| EDIT: oh ew, grandparent comment is a bot. How did you
| recognize it?
| ventuss_ovo wrote:
| interesting point about immutability
| alanning wrote:
| The Temporal Cookbook on TC39's site provides examples of how
| using the new API looks/feels:
|
| https://tc39.es/proposal-temporal/docs/cookbook.html
|
| For example, calc days until a future date:
| https://tc39.es/proposal-temporal/docs/cookbook.html#how-man...
|
| ...or, compare meeting times across timezones:
| https://tc39.es/proposal-temporal/docs/cookbook.html#book-a-...
| kemitchell wrote:
| > The first proposal I worked on was Promise.allSettled, which
| was fulfilling.
|
| Har har.
| Animats wrote:
| I went through a similar decade-long fire drill around ISO8601
| date parsing in Python.[1] Issue started in 2012, and after about
| a decade a solution was in the standard library.
|
| [1] https://groups.google.com/g/comp.lang.python/c/Q2w4R89Nq1w
| baliex wrote:
| Thank you thank you thank you.
|
| Parsing dates with anything other than fromisoformat feels
| totally backwards in comparison. We were using ciso8601 until
| fromisoformat was in the standard library. And now things are
| incredibly simple and reliable.
| Vinnl wrote:
| > Whilst Firefox was able to implement Temporal as it was being
| specced - thanks to the great work of Andre Bargull (known online
| as Anba)
|
| It's worth highlighting that Andre is actually a volunteer
| contributor who managed to implement the whole thing by
| themselves.
| bpiroman wrote:
| I wish JavaScript held onto the name Mocha :)
| tmpfile wrote:
| I'd like to have interval types for example
| const D = new Temporal() const t = new
| Interval({minutes:5}) const v = D.add(t)
| wesselbindt wrote:
| I'm very happy about this. The fact that Temporal forces you to
| actually deal with the inherent complexities of time management
| (primarily the distinction between an instant and a calendar
| datetime) makes it incredibly difficult to make the mistakes that
| Date almost seems designed to cause. It's a bit more verbose, but
| I'll take writing a handful of extra characters over being called
| at 3AM to fix a DST related bug any day of the week.
___________________________________________________________________
(page generated 2026-03-11 23:00 UTC)