Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript Temporal is coming

developer.mozilla.org

Post reply on HN
Print view View original

141–150 of 416 posts

Re: JavaScript Temporal is coming

#141

Post by scarface_74 »

hajile wrote: post #134
klabb3 wrote: post #63

Earlier quoted context omitted.

> 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.

JS could be an amazing language to work with if they'd just spec out a "use type" subset that uses an actually-sound Hindley-Milner type system on typed parts (verify types at the untyped fringes and throw if they don't match) while disallowing all the bad parts like type coercion or any of the many other footguns in the language.

TypeScript??

Re: JavaScript Temporal is coming

#142

Post by burntsushi »

jrochkind1 wrote: post #133
vlovich123 wrote: post #86

Earlier quoted context omitted.

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…

It does not assume that -- implementing libraries need to -- and do, in practice right now -- implement the rules for jurisdictions change the rules for offsets. 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 t…

> 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!

Which libraries do this? Libraries usually implement proleptic calendars, including Temporal[1], which specifically do not account for shifts like this. And indeed, the Temporal docs even call out this specific example.

(I agree with the rest of your comment!)

[1]: https://tc39.es/proposal-temporal/docs/calendars.html#handli...

Re: JavaScript Temporal is coming

#144

Post by 3pt14159 »

moi2388 wrote: post #66
AndrewStephens wrote: post #61

Earlier quoted context omitted.

And lived on a flat planet.

That’s not a valid argument. There is no reason why people in Japan couldn’t start their workday at 03:00, or people in France at 22:00

Travelling would be so much more annoying if we did it that way. Imagine constantly having to double check what the local time is for getting out of bed.

Re: JavaScript Temporal is coming

#145

Post by MobiusHorizons »

tomtomtom777 wrote: post #28
phiresky wrote: post #23

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…

> It even solves the serialization issue of the difference between a "fixed-offset" timestamp (e.g. 2025-01-01T00:00+02:00) and one in a specific timezone (e.g. Europe/Paris). Could you elaborate on that? What is the issue?

Places like Europe/Paris or America/Los Angeles can participate in daylight savings, and if they do, they may have different schedules, and those schedules may change at different points in history due to the passing of laws. Europe and the us already have a different schedule for daylight savings, and the whole west coast is trying to opt into permanent daylight savings for the last several years. But that would require an act of congress.

Programmatically it mostly means you have to ship metadata about how the offsets change over time, which needs to be updated periodically. Browsers already ship that metadata, so it is really nice to finally have a way to access it from JavaScript without shipping the extra few tens of kilobytes.

Re: JavaScript Temporal is coming

#146

Post by qwertox »

Man, that took some time to find in the docs:

Temporal.ZonedDateTime.prototype.withTimeZone() [0], which allows to convert from one timezone to another

   const meetingTime = Temporal.ZonedDateTime.from(
     "2021-08-01T12:00[America/New_York]",
   );

   const meetingTimeInParis = meetingTime.withTimeZone("Europe/Paris");
 
   console.log(meetingTimeInParis.toString()); // 2021-08-01T18:00:00+02:00[Europe/Paris]
To me, timezone translations as well as durations are such an essential thing which libraries must handle, and it's nice to see that Temporal handles both. But it looks like Temporal.Duration doesn't offer a custom `format` function, for example `duration.format('H\hmm\m')` or something like that to format a duration into 1h03m.

[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Re: JavaScript Temporal is coming

#147

Post by jjice »

CharlieDigital wrote: post #106
jjice wrote: post #91

Wow, this is great! We were using the proposal library at my job when I first joined, but switched to moment since Temporal seemed frozen. For what it's worth, moment is excellent too, but having good datetime support in the standard library is going to be fantastic.

FYI, the Moment.js docs recommend not using Moment.js[0] > We now generally consider Moment to be a legacy project in maintenance mode. It is not dead, but it is indeed done. The author spells out a few pitfalls of Moment's design and why they're not addressing these as well as alternatives (Luxon, Day.js, date-fns, js-Joda) I've switched to Day.js instead[1] [0] https://momentjs.com/docs/#/-project-status/ [1] https…

Oh thanks for the rec! I was aware that Moment was marking itself as legacy, but Day.js looks like a bonus here. Hopefully we can begin making the Temporal transition over the next few years though.

Re: JavaScript Temporal is coming

#148

Post by yread »

numbsafari wrote: post #109
yread wrote: post #98

Earlier quoted context omitted.

why does the polyfill have dependencies? And it's 200KB alone compared to 60KB of moment.

Did you bother to look at it? It has a single dependency, and that single dependency has no dependencies of its own. So what is that dependency? "temporal-spec" And it looks like it comes from the same github repo. It basically looks like they broke out the API definitions so that they could be depended on by other potential implementations. This isn't atypical.

Oh sorry I was looking at https://www.npmjs.com/package/@js-temporal/polyfill

this one looks much better indeed

Re: JavaScript Temporal is coming

#149

Post by inbx0 »

nobleach wrote: post #13

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…

It's great that Temporal is coming, and I'm sure there are bunch of other nice things coming up too, but unfortunately I don't share your optimism with the specific proposals that you mention (even though those would be very nice).

Pipelines, pattern matching and records+tuples have all been in the works for 4+ years, and are all still in stages 1-2. I don't think any of them has seen any significant progress in the past year, except maybe pattern matching. According to an issue in the records and tuples repo, there's been pushback on the value semantics of it (i.e. whether === can be made to work). Dropping value semantics would significantly reduce the whole proposal's usefulness.

I think all of them are at least a year or two away from reaching stage 3, if they ever do. But hey at least we now have array grouping functions.

Re: JavaScript Temporal is coming

#150

Post by mason55 »

Cthulhu_ wrote: post #69
amiga386 wrote: post #57

Earlier quoted context omitted.

+02:00 is not political. It's an offset from UTC and will be the same offset in the past and future. Europe/Paris is political. It defines that offsets change at certain times of the year, but that could change tomorrow, or the political boundary that the timezone applies to could split such that the person or entity needing a time in their "local" timezone finds another one needs to be picked (see various US states/…

I wonder what happens when a timezone ceases to exist, e.g. what if Paris is renamed to New New York after the British take revenge and take over France.

Here are a couple starting points

https://medium.com/servicios-a0/on-solving-the-tzdb-changes-...

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

Post reply on HN