7 ms·

JS has been moving forward with a new Date/Time API called Temporal[1]. I haven't had a chance to use it myself, but a friend dropped Moment.js for it (I think

JS has been moving forward with a new Date/Time API called Temporal[1]. I haven't had a chance to use it myself, but a friend dropped Moment.js for it (I think to keep the browser from adjusting the date to the local time). New APIs (and hence, Temporal) are the type of things that if you don't know about, you can easily miss and go straight to a library for. [1]: https://2ality.com/2021/06/temporal-api.html https://2ality.com/2021/06/temporal-api.html

wruza 5y ago
Oh wow, someone finally took it serious. Everyone: visit the link if you didn’t yet. Abstract dates, durations, easy dmy math, mostly everyday developer-friendly. Dates are one of these computer topics that seem familiar (just like numbers in a floating point form) but are hard to operate on. And if the language’s core date/time library is poor man’s one, it’s better to not have it at all.
smichel17 5y ago
How do they compare to Luxon?
- merb 5y ago
  they might get built-in https://caniuse.com/temporal https://caniuse.com/temporal? (https://tc39.es/proposal-temporal/docs/ https://tc39.es/proposal-temporal/docs/) (https://github.com/tc39/proposal-temporal https://github.com/tc39/proposal-temporal) > NOTE: Although this proposal's API is not expected to change, implementers of this proposal MUST NOT ship unflagged Temporal implementations until IETF standardizes timezone/calendar string serialization formats. See #1450 for updates. it's basically already accepted. Stage 3 means it's basically ready for a preview implementation and stage 4 means passed for "official" ecmascript inclusion
eyelidlessness 5y ago
I tried to use Temporal just this past week, and I have to be honest… the spec and documentation are painful. I spent three full days with it and still don’t understand why it’s designed the way it is. Other recent additions to stdlib have followed a fairly consistent pattern: design low level but with existing use cases and solutions in mind, explain the design in terms of migration path for library authors or in terms of usage comparisons to those libraries. Temporal just has… a bunch of data types with very little in the way of explanation of what they are. And some of them are quite similar but have slightly different semantics and APIs to achieve the same thing. It’s not entirely clear why most of the data types exist in the first place. Like, I don’t want a TimeZone class, and I don’t want multiple kinds of Instants. I want a Date, a Duration, and clear semantics about how they interact with each other and with time zones. Anyway I ended up putting the work I was doing on hold because it became such a time sink, but when I come back to it I fully expect to look at my WIP stashes, and run screaming toward date-fns or whatever. I mean no disrespect to the standards authors/contributors (in case any are reading), I’m sure standardizing anything to do with dates/times is even more challenging than anything else you deal with. I just… wonder if the low level design approach may have forced an unnecessary design in this case, and wish there was a somewhat more pragmatic approach for something end users and library authors alike routinely get wrong in subtle but important ways.
- Macha 5y ago
  > I want a Date, a Duration, and clear semantics about how they interact with each other and with time zones. I think at this stage the only libraries I've seen to manage this clearly are the ones that cleanly seperate the concept of "LocalDate[Time]" from "ZonedDateTime" (which is different to OffsetDateTime, which is only useful when backwards looking because offsets are subject to change in future, and so you should probably just use a Zoned variant). While people might appreciate the simplicity of a single DateTime class, it just leads to unclear handling in application code of where the conversions happening and confusion as to what's actually going on with time zones.
  - eyelidlessness 5y ago
    This could be addressed at least for the most common cases by making the API more explicit: if you want a non-zoned DateTime, you have to say so and accept its caveats. Otherwise you’re getting a (local by default) zoned DateTime and its TZ can be manipulated to accomplish other date/time math in a predictable way. The mix of zoned/not is a valid use case but almost certainly a specialized one that shouldn’t be the core API.
    - dvt 5y ago
      > The mix of zoned/not is a valid use case but almost certainly a specialized one that shouldn’t be the core API. I'm curious, where is this ever a valid use case? The idea of an unzoned DateTime doesn't make sense to me. I guess if you're building software that lives in orbit or on other planets?
      - eyelidlessness 5y ago
        My personal use case that I explain in the “just use UTC isn’t good enough” case: I take meds 2-3 times a day that are short acting and time sensitive. I need them at ~9am and ~1pm to function. Local time, wherever I am. For the unzoned case I need my reminders to notify me at the same local time wherever I travel. For the mixed case I need to be able to apply local changes where the unzoned solution isn’t available. These are ADHD meds, I have severe executive dysfunction and I depend on reminders for this. Traveling from Seattle to DC, this is literally the difference of whether I can function at all before lunchtime. Traveling further I might as well not go at all.
brundolf 5y ago
Temporal isn't fully stabilized yet. There's a polyfill, but it may still get breaking changes down the line. We're waiting on the polyfill to stabilize before switching.
dvdkon 5y ago
This looks great, covering about what I'd want from a modern date/time library, but threre seems to be a huge ommision: Is there seriously no way to format/parse dates and times based on arbitrary format specifications? C has functions for that! Why is JS so resistant to this crucial functionality?
- FrontAid 5y ago
  Formatting (without "arbitrary format specifications") has been available for years: - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat/DateTimeFormat https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... - https://caniuse.com/mdn-javascript_builtins_intl_datetimeformat_format https://caniuse.com/mdn-javascript_builtins_intl_datetimefor... Parsing, however, is an entirely different topic. I assume the Temporal proposal authors learned from the Date.parse fiasco. To this day, there are browser inconsistiencies that make it largely unusable for anything else than the full-length ISO date format. Hence, it might be better to use a userland library that works consistently regardless of the browser (version). There are also some notes about parsing in https://tc39.es/proposal-temporal/docs/parse-draft.html https://tc39.es/proposal-temporal/docs/parse-draft.html: > Temporal's approach to most operations—including parsing—is to encourage strong typing, e.g. Temporal.Instant.from vs. Temporal.PlainDateTime.from. A type-spanning "parse anything" API goes against that strongly-typed model.
  - dvdkon 5y ago
    Yes, it's always been possible to get some kind of string from datetimes, but I specifically care about specifying what string, same with parsing. "Just use a locale's default" might work if you're making a web app for clients who aren't picky, but using JS as a "serious" language it's a really big hole. There's plenty of formats that demand non-ISO date formats and I currently need to use a third-party library. I've gotten used to than in JS, but I was hoping a new take on dates will sort this out. Oh well, I'll have to just hope it makes it to v2: https://github.com/js-temporal/proposal-temporal-v2 https://github.com/js-temporal/proposal-temporal-v2.
    - 5y ago

wruza 5y ago

Oh wow, someone finally took it serious. Everyone: visit the link if you didn’t yet. Abstract dates, durations, easy dmy math, mostly everyday developer-friendly. Dates are one of these computer topics that seem familiar (just like numbers in a floating point form) but are hard to operate on. And if the language’s core date/time library is poor man’s one, it’s better to not have it at all.

smichel17 5y ago

How do they compare to Luxon?

merb 5y ago
they might get built-in https://caniuse.com/temporal https://caniuse.com/temporal? (https://tc39.es/proposal-temporal/docs/ https://tc39.es/proposal-temporal/docs/) (https://github.com/tc39/proposal-temporal https://github.com/tc39/proposal-temporal) > NOTE: Although this proposal's API is not expected to change, implementers of this proposal MUST NOT ship unflagged Temporal implementations until IETF standardizes timezone/calendar string serialization formats. See #1450 for updates. it's basically already accepted. Stage 3 means it's basically ready for a preview implementation and stage 4 means passed for "official" ecmascript inclusion

eyelidlessness 5y ago

I tried to use Temporal just this past week, and I have to be honest… the spec and documentation are painful. I spent three full days with it and still don’t understand why it’s designed the way it is. Other recent additions to stdlib have followed a fairly consistent pattern: design low level but with existing use cases and solutions in mind, explain the design in terms of migration path for library authors or in terms of usage comparisons to those libraries. Temporal just has… a bunch of data types with very little in the way of explanation of what they are. And some of them are quite similar but have slightly different semantics and APIs to achieve the same thing. It’s not entirely clear why most of the data types exist in the first place. Like, I don’t want a TimeZone class, and I don’t want multiple kinds of Instants. I want a Date, a Duration, and clear semantics about how they interact with each other and with time zones. Anyway I ended up putting the work I was doing on hold because it became such a time sink, but when I come back to it I fully expect to look at my WIP stashes, and run screaming toward date-fns or whatever. I mean no disrespect to the standards authors/contributors (in case any are reading), I’m sure standardizing anything to do with dates/times is even more challenging than anything else you deal with. I just… wonder if the low level design approach may have forced an unnecessary design in this case, and wish there was a somewhat more pragmatic approach for something end users and library authors alike routinely get wrong in subtle but important ways.

Macha 5y ago
> I want a Date, a Duration, and clear semantics about how they interact with each other and with time zones. I think at this stage the only libraries I've seen to manage this clearly are the ones that cleanly seperate the concept of "LocalDate[Time]" from "ZonedDateTime" (which is different to OffsetDateTime, which is only useful when backwards looking because offsets are subject to change in future, and so you should probably just use a Zoned variant). While people might appreciate the simplicity of a single DateTime class, it just leads to unclear handling in application code of where the conversions happening and confusion as to what's actually going on with time zones.
- eyelidlessness 5y ago
  This could be addressed at least for the most common cases by making the API more explicit: if you want a non-zoned DateTime, you have to say so and accept its caveats. Otherwise you’re getting a (local by default) zoned DateTime and its TZ can be manipulated to accomplish other date/time math in a predictable way. The mix of zoned/not is a valid use case but almost certainly a specialized one that shouldn’t be the core API.
  - dvt 5y ago
    > The mix of zoned/not is a valid use case but almost certainly a specialized one that shouldn’t be the core API. I'm curious, where is this ever a valid use case? The idea of an unzoned DateTime doesn't make sense to me. I guess if you're building software that lives in orbit or on other planets?
    - eyelidlessness 5y ago
      My personal use case that I explain in the “just use UTC isn’t good enough” case: I take meds 2-3 times a day that are short acting and time sensitive. I need them at ~9am and ~1pm to function. Local time, wherever I am. For the unzoned case I need my reminders to notify me at the same local time wherever I travel. For the mixed case I need to be able to apply local changes where the unzoned solution isn’t available. These are ADHD meds, I have severe executive dysfunction and I depend on reminders for this. Traveling from Seattle to DC, this is literally the difference of whether I can function at all before lunchtime. Traveling further I might as well not go at all.

brundolf 5y ago

Temporal isn't fully stabilized yet. There's a polyfill, but it may still get breaking changes down the line. We're waiting on the polyfill to stabilize before switching.

dvdkon 5y ago

This looks great, covering about what I'd want from a modern date/time library, but threre seems to be a huge ommision: Is there seriously no way to format/parse dates and times based on arbitrary format specifications? C has functions for that! Why is JS so resistant to this crucial functionality?

FrontAid 5y ago
Formatting (without "arbitrary format specifications") has been available for years: - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat/DateTimeFormat https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... - https://caniuse.com/mdn-javascript_builtins_intl_datetimeformat_format https://caniuse.com/mdn-javascript_builtins_intl_datetimefor... Parsing, however, is an entirely different topic. I assume the Temporal proposal authors learned from the Date.parse fiasco. To this day, there are browser inconsistiencies that make it largely unusable for anything else than the full-length ISO date format. Hence, it might be better to use a userland library that works consistently regardless of the browser (version). There are also some notes about parsing in https://tc39.es/proposal-temporal/docs/parse-draft.html https://tc39.es/proposal-temporal/docs/parse-draft.html: > Temporal's approach to most operations—including parsing—is to encourage strong typing, e.g. Temporal.Instant.from vs. Temporal.PlainDateTime.from. A type-spanning "parse anything" API goes against that strongly-typed model.
- dvdkon 5y ago
  Yes, it's always been possible to get some kind of string from datetimes, but I specifically care about specifying what string, same with parsing. "Just use a locale's default" might work if you're making a web app for clients who aren't picky, but using JS as a "serious" language it's a really big hole. There's plenty of formats that demand non-ISO date formats and I currently need to use a third-party library. I've gotten used to than in JS, but I was hoping a new take on dates will sort this out. Oh well, I'll have to just hope it makes it to v2: https://github.com/js-temporal/proposal-temporal-v2 https://github.com/js-temporal/proposal-temporal-v2.
  - 5y ago