11 ms·

Is It Time for the JavaScript Temporal API?

156 points by ceeb 5y ago

TameAntelope 5y ago
> Modern alternatives such as Day.js and date-fns may be better but should a library necessary when your app has minimal date-handling requirements? Yes? Or at least, I don't think this is the, "obvious question that leads to the rest of the article" that the author may have assumed. As another commenter mentioned, Day.js is 2kb. That's the answer: use Day.js. But I guess that doesn't get you a blog post you can reference when applying to jobs, so here we are.
- nobleach 5y ago
  From someone who used MomentJS back in the day, Day.js is such a nicer alternative! Moment was like 59k or something!
toomanybeersies 5y ago
I'm happy to see that it includes primitives of varying precision, specifically, that it includes PlainDate [1], which represents a calendar date, with no timezone. This year, I've spent far too many days, probably weeks, fixing tedious bugs due to incorrect handling and parsing/formatting/reparsing of dates. [1] https://tc39.es/proposal-temporal/docs/plaindate.html https://tc39.es/proposal-temporal/docs/plaindate.html
MathMonkeyMan 5y ago
Douglas Crockford has a sketch of a datetime library in his book, How JavaScript Works. I like it. Here's a summary. A datetime has three representations: - (real) number of milliseconds since the epoch, - string in some standard format (e.g. ISO 8601), - plain old object with the following properties: year, month (one-based), day, hour, minute, second (real), zone, week, weekday. Then there are four functions for generating datetimes and converting among the representations: - Date.now() -> Number - Date.object(Number | String, zone info? ...) -> Object - Date.string(Number | Object, format and/or zone info? ...) -> String - Date.number(Object | String, format and/or zone info? ...) -> Number You'd need the tz database under the hood and maybe exceptions for impossible or ambiguous datetimes. Aside from bundling the tz database, I don't see this library needing to be very large. And if it's small, it's not a big deal if it isn't standard.
livinglist 5y ago
I kinda agreed
tmikaeld 5y ago
Awesome, hoping to see this in Cloudflare Workers as soon as V8 has it! (Currently using day.js)
llimos 5y ago
Betteridge's law does not apply here!
rco8786 5y ago
> 74Kb payload Is 74Kb really a cause for concern on modern internet connections? I realize death by 1,000 cuts, etc...but for such a core set of functionality that seems pretty reasonable. DayJs is 2 (two) Kb. Perfectly reasonable for any app with minimal date handling needs. (BTW I'm 100% in support of a native temporal API also, although have some gripes with the Dev Exp of what's shown in this post)
- nobleach 5y ago
  My take: ABSOLUTELY! 74kb or image data? Probably not. But unzipping, parsing/JITting/running/whatever that large of a payload.... on crappy 3 year old low-memory Android devices... yes. That is going to lag. Not too long ago, Google tried to push AMP on all of us because devs were getting way too careless with their bundle sizes. We're still not to a decent place just yet. Internet speeds in The United States, Europe and populated Asia may be growing but there's an entire world that are still at "slow-3G" speeds.
- enumjorge 5y ago
  There are a lot of places in the world and even the US where people have slow connections. It’s also not just download speed that’s the problem. Slower phones need to process all that JS. I’d say that time-related API being core functionality makes it more of a reason why this should be baked into the standard JS API. Why make users download something that most sites and web apps use?
- mkotowski 5y ago
  From my personal experience in Poland: You can have LTE+ or even 5G in cities, but traveling by train means that in some areas only a select few extra-lightweight pages like Hacker News are able to load before a timeout or connection loss occurs. So yes, in some situations even that amount of payload could have a meaningful impact. “Modern” connections are irrelevant if we are talking about regions, which are not viable for a high-speed infrastructure. And such places are almost everywhere. Mountainous parts of Japan, many American regions, or sparsely populated Polish regions. Of course, how much it is important varies greatly.
- onion2k 5y ago
mikeocool 5y ago
Wahoo, it doesn't use 0-indexed months! Probably the biggest cause of bugs with js Date objects.
- postalrat 5y ago
  Years aren't 0-indexed either. Nobody has a problem with that.
  - jessaustin 5y ago
    How do you know they aren't? What happened in 1 CE? What happened in 1 BCE? What happened during the year in between?
    - postalrat 5y ago
      There isn't a year between them.
      - jessaustin 5y ago
        In most calendar systems there is. Perhaps there isn't in your favorite calendar, or perhaps you just don't know about it. For instance, the subject of TFA is based on the "Proleptic Gregorian", which does have a year zero.
- mkotowski 5y ago
  That does remind me: why that even is a thing? Ordering days of a week from zero can make sense since there is Monday/Sunday as a week start divide, and this can be seen as a bypass (0/7 as Sunday and 1 as a Monday), but with months?
  - mikewhy 5y ago
    https://stackoverflow.com/a/41992352 https://stackoverflow.com/a/41992352
devadvance 5y ago
Excited to get to use this. One area of concern is i18n. The article touches on this briefly at the end, but I hope a zoned value can be used with Intl as well; having to use only Plain values would be frustrating.
the__alchemist 5y ago
Both the builtin lib, and the popular moment lib are missing separate date and time types, which leads to subtle errors. (ie when using their workaround of using datetime types for either). From the article, it appears Temporal has the same problem. There's nothing wrong with mutable types, which is common in JS discussions; the problem is when the API mutates in place where this isn't obvious. I hand-wrote date and dt types with basic operations instead. Limited functionality, eg timezones, formatting etc, but behaves as you'd expect. Another option might be to wrap Rust's Chrono lib in WASM, then call from JS; it's the best DT lib I've seen in any language.
- spankalee 5y ago
  There is a separate time type: https://tc39.es/proposal-temporal/docs/plaintime.html https://tc39.es/proposal-temporal/docs/plaintime.html
  - the__alchemist 5y ago
    Awesome. It looks like it has a PlainDate type as well.
yashap 5y ago
Nice, it looks to be quite similar to the Java 8 date/time APIs (java.time.*), which are excellent. Looking forward to this!
- bluedevil2k 5y ago
  There’s a direct JS port of Java time as well - https://js-joda.github.io/js-joda/ https://js-joda.github.io/js-joda/
- ferdowsi 5y ago
  Ironic because Javascript's Date behavior was also modeled after the original java.Util.Date (which was immediately deprecated, whoops).
  - stickfigure 5y ago
    Why is that ironic?
    - lstamour 5y ago
      Because copying Java got them into this mess? ;-)
      - yashap 5y ago
        Yeah, but the Java 8 date/time API has been around for ~7-8 years, and is basically universally loved, while the original java.util.Date was hated for ages. Plus Java 8 date/time is based extremely strongly on joda-time, which hit 1.0 about a decade before that, and was also pretty universally loved. So we're dealing with an API that has been considered great, and an excellent way to deal with dates/times, for nearly 2 decades. Seems like a safe bet to copy :)
dragonwriter 5y ago
Temporal is great, and the sooner it lands and is usable the better (AFAIK, there isn't a production-grade polyfill yet.) In the interim, JS-Joda [0] seems pretty decent, and doesn't use the wrapper approach. [0] https://js-joda.github.io/js-joda/ https://js-joda.github.io/js-joda/
- aidos 5y ago
  I’ve been keeping an eye on it myself. The implementation in Chrome looks pretty complete already, which is promising. I don’t quite get the point of the other libraries like moment etc. They have a bunch of convenience stuff, but unless you’ve modelled the different types of times that crop up in real life, it’s all a bit pointless. When I first read through the Temporal api, I was physically nodding along in agreement. It’s dates and times done right in js. Can’t wait to be able to use it.
- httgp 5y ago
  My favorite has always been Day.js [0] - it is really small, has a very clean API, great documentation and does pretty much everything I want. [0] https://day.js.org/ https://day.js.org/
  - aidos 5y ago
    It’s not really the same thing though, right? It doesn’t handle instants vs zonedtimes etc. Even the simplest of future cases is handled poorly by these other libraries. If you want to say that something happens on a certain date in the future (say, a due date), your only option is to use an instant as an approximation (often midnight utc on that day). It works ok, but you’re better to have a proper datatype that represents a day without a time and timezone component (it’s effectively a 50hr ish window). Temporal gives you all that and more.
  - moogly 5y ago
    Used that as a replacement for momentjs until we had to make things seriously timezone-aware, and some quite crippling tz bugs (granted, probably 2 years ago now) made us move to Luxon. That worked well, but I'm glad to have something JodaTime-ish coming now that doesn't conflate instants with zoned datetimes with durations.
adam_arthur 5y ago
Anyone know why all new Ecmascript APIs are implemented to be used as "newable classes" rather than ordinary functions? The community seems to be moving towards functional programming/away from classes.. and pretty much every mainstream JS lib is function rather than class oriented (yes, I know classes are simply special functions) Also adds unnecessary verbosity/more syntax noise. Is there some internal performance reason for why ordinary functions couldn't be optimized to perform the same as "new"? (Seems like it would be easy to wire the prototype internally to the function, resulting in same semantics). At this point better to be consistent, but I'd still use a date library just to avoid added verbosity of this native solution. Luxon API reads a lot better than this... Though I'm sure there are reasons a standard implementation needs added complexity (has to cover every edge case)
- oaiey 5y ago
  Because most original API (DOM, browser, date, etc) are OO oriented and you stick your standard library in one pattern. And speaking of everyone moving to functional programming: i work with several hundred developers in four continents in a very dynamic envirnment.... And I have not seen a FP advocate. Not that FP is not good (I prefer it where applicable) but mindset/winning/moving towards are words I would not choose when it comes to describing the state of FP and OO in the world. There is a strong influence but not to a degree where an established language changes its core paradigm: see Java, C#, JS, ...
  - lnxg33k1 5y ago
    I would be more prone to say that the original API are something that came up by using buzzwords from growing languages or something else, for sure they're a thing, but like it's not that `new` makes an OOP approach if then you miss inheritance, abstraction, encapsulation and polymorphism, I'm not sure if I am being picky but like if there is just a keyword and nothing else more important to the paradigm then I think it might be confusing for some reader to see something like that statement
  - jacksnipe 5y ago
    Really? I have seen — across many jobs and company sizes and frameworks, over about a decade — a slow but inexorable trend of moving toward FP. Be it in React, where hooks are pushing everything to be functional; to the fact that Monads have started showing up in unexpected places in codebases I’ve worked on; to the fundamentally functional nature of frameworks I have to use every day working at a FAANG. Along the way, until the FAANG, I never met any functional advocates. What I did meet are people who reach for the appropriate functional tools when building solutions; others see the much better solutions they arrive at, and copy.

156 points by ceeb 5y ago

> Modern alternatives such as Day.js and date-fns may be better but should a library necessary when your app has minimal date-handling requirements? Yes? Or at least, I don't think this is the, "obvious question that leads to the rest of the article" that the author may have assumed. As another commenter mentioned, Day.js is 2kb. That's the answer: use Day.js. But I guess that doesn't get you a blog post you can reference when applying to jobs, so here we are.

nobleach 5y ago
From someone who used MomentJS back in the day, Day.js is such a nicer alternative! Moment was like 59k or something!

toomanybeersies 5y ago

I'm happy to see that it includes primitives of varying precision, specifically, that it includes PlainDate [1], which represents a calendar date, with no timezone. This year, I've spent far too many days, probably weeks, fixing tedious bugs due to incorrect handling and parsing/formatting/reparsing of dates. [1] https://tc39.es/proposal-temporal/docs/plaindate.html https://tc39.es/proposal-temporal/docs/plaindate.html

MathMonkeyMan 5y ago

Douglas Crockford has a sketch of a datetime library in his book, How JavaScript Works. I like it. Here's a summary. A datetime has three representations: - (real) number of milliseconds since the epoch, - string in some standard format (e.g. ISO 8601), - plain old object with the following properties: year, month (one-based), day, hour, minute, second (real), zone, week, weekday. Then there are four functions for generating datetimes and converting among the representations: - Date.now() -> Number - Date.object(Number | String, zone info? ...) -> Object - Date.string(Number | Object, format and/or zone info? ...) -> String - Date.number(Object | String, format and/or zone info? ...) -> Number You'd need the tz database under the hood and maybe exceptions for impossible or ambiguous datetimes. Aside from bundling the tz database, I don't see this library needing to be very large. And if it's small, it's not a big deal if it isn't standard.

livinglist 5y ago

I kinda agreed

tmikaeld 5y ago

Awesome, hoping to see this in Cloudflare Workers as soon as V8 has it! (Currently using day.js)

llimos 5y ago

Betteridge's law does not apply here!

rco8786 5y ago

> 74Kb payload Is 74Kb really a cause for concern on modern internet connections? I realize death by 1,000 cuts, etc...but for such a core set of functionality that seems pretty reasonable. DayJs is 2 (two) Kb. Perfectly reasonable for any app with minimal date handling needs. (BTW I'm 100% in support of a native temporal API also, although have some gripes with the Dev Exp of what's shown in this post)

nobleach 5y ago
My take: ABSOLUTELY! 74kb or image data? Probably not. But unzipping, parsing/JITting/running/whatever that large of a payload.... on crappy 3 year old low-memory Android devices... yes. That is going to lag. Not too long ago, Google tried to push AMP on all of us because devs were getting way too careless with their bundle sizes. We're still not to a decent place just yet. Internet speeds in The United States, Europe and populated Asia may be growing but there's an entire world that are still at "slow-3G" speeds.
enumjorge 5y ago
There are a lot of places in the world and even the US where people have slow connections. It’s also not just download speed that’s the problem. Slower phones need to process all that JS. I’d say that time-related API being core functionality makes it more of a reason why this should be baked into the standard JS API. Why make users download something that most sites and web apps use?
mkotowski 5y ago
From my personal experience in Poland: You can have LTE+ or even 5G in cities, but traveling by train means that in some areas only a select few extra-lightweight pages like Hacker News are able to load before a timeout or connection loss occurs. So yes, in some situations even that amount of payload could have a meaningful impact. “Modern” connections are irrelevant if we are talking about regions, which are not viable for a high-speed infrastructure. And such places are almost everywhere. Mountainous parts of Japan, many American regions, or sparsely populated Polish regions. Of course, how much it is important varies greatly.
onion2k 5y ago

mikeocool 5y ago

Wahoo, it doesn't use 0-indexed months! Probably the biggest cause of bugs with js Date objects.

postalrat 5y ago
Years aren't 0-indexed either. Nobody has a problem with that.
- jessaustin 5y ago
  How do you know they aren't? What happened in 1 CE? What happened in 1 BCE? What happened during the year in between?
  - postalrat 5y ago
    There isn't a year between them.
    - jessaustin 5y ago
      In most calendar systems there is. Perhaps there isn't in your favorite calendar, or perhaps you just don't know about it. For instance, the subject of TFA is based on the "Proleptic Gregorian", which does have a year zero.
mkotowski 5y ago
That does remind me: why that even is a thing? Ordering days of a week from zero can make sense since there is Monday/Sunday as a week start divide, and this can be seen as a bypass (0/7 as Sunday and 1 as a Monday), but with months?
- mikewhy 5y ago
  https://stackoverflow.com/a/41992352 https://stackoverflow.com/a/41992352

devadvance 5y ago

Excited to get to use this. One area of concern is i18n. The article touches on this briefly at the end, but I hope a zoned value can be used with Intl as well; having to use only Plain values would be frustrating.

the__alchemist 5y ago

Both the builtin lib, and the popular moment lib are missing separate date and time types, which leads to subtle errors. (ie when using their workaround of using datetime types for either). From the article, it appears Temporal has the same problem. There's nothing wrong with mutable types, which is common in JS discussions; the problem is when the API mutates in place where this isn't obvious. I hand-wrote date and dt types with basic operations instead. Limited functionality, eg timezones, formatting etc, but behaves as you'd expect. Another option might be to wrap Rust's Chrono lib in WASM, then call from JS; it's the best DT lib I've seen in any language.

spankalee 5y ago
There is a separate time type: https://tc39.es/proposal-temporal/docs/plaintime.html https://tc39.es/proposal-temporal/docs/plaintime.html
- the__alchemist 5y ago
  Awesome. It looks like it has a PlainDate type as well.

yashap 5y ago

Nice, it looks to be quite similar to the Java 8 date/time APIs (java.time.*), which are excellent. Looking forward to this!

bluedevil2k 5y ago
There’s a direct JS port of Java time as well - https://js-joda.github.io/js-joda/ https://js-joda.github.io/js-joda/
ferdowsi 5y ago
Ironic because Javascript's Date behavior was also modeled after the original java.Util.Date (which was immediately deprecated, whoops).
- stickfigure 5y ago
  Why is that ironic?
  - lstamour 5y ago
    Because copying Java got them into this mess? ;-)
    - yashap 5y ago
      Yeah, but the Java 8 date/time API has been around for ~7-8 years, and is basically universally loved, while the original java.util.Date was hated for ages. Plus Java 8 date/time is based extremely strongly on joda-time, which hit 1.0 about a decade before that, and was also pretty universally loved. So we're dealing with an API that has been considered great, and an excellent way to deal with dates/times, for nearly 2 decades. Seems like a safe bet to copy :)

dragonwriter 5y ago

Temporal is great, and the sooner it lands and is usable the better (AFAIK, there isn't a production-grade polyfill yet.) In the interim, JS-Joda [0] seems pretty decent, and doesn't use the wrapper approach. [0] https://js-joda.github.io/js-joda/ https://js-joda.github.io/js-joda/

aidos 5y ago
I’ve been keeping an eye on it myself. The implementation in Chrome looks pretty complete already, which is promising. I don’t quite get the point of the other libraries like moment etc. They have a bunch of convenience stuff, but unless you’ve modelled the different types of times that crop up in real life, it’s all a bit pointless. When I first read through the Temporal api, I was physically nodding along in agreement. It’s dates and times done right in js. Can’t wait to be able to use it.
httgp 5y ago
My favorite has always been Day.js [0] - it is really small, has a very clean API, great documentation and does pretty much everything I want. [0] https://day.js.org/ https://day.js.org/
- aidos 5y ago
  It’s not really the same thing though, right? It doesn’t handle instants vs zonedtimes etc. Even the simplest of future cases is handled poorly by these other libraries. If you want to say that something happens on a certain date in the future (say, a due date), your only option is to use an instant as an approximation (often midnight utc on that day). It works ok, but you’re better to have a proper datatype that represents a day without a time and timezone component (it’s effectively a 50hr ish window). Temporal gives you all that and more.
- moogly 5y ago
  Used that as a replacement for momentjs until we had to make things seriously timezone-aware, and some quite crippling tz bugs (granted, probably 2 years ago now) made us move to Luxon. That worked well, but I'm glad to have something JodaTime-ish coming now that doesn't conflate instants with zoned datetimes with durations.

adam_arthur 5y ago

Anyone know why all new Ecmascript APIs are implemented to be used as "newable classes" rather than ordinary functions? The community seems to be moving towards functional programming/away from classes.. and pretty much every mainstream JS lib is function rather than class oriented (yes, I know classes are simply special functions) Also adds unnecessary verbosity/more syntax noise. Is there some internal performance reason for why ordinary functions couldn't be optimized to perform the same as "new"? (Seems like it would be easy to wire the prototype internally to the function, resulting in same semantics). At this point better to be consistent, but I'd still use a date library just to avoid added verbosity of this native solution. Luxon API reads a lot better than this... Though I'm sure there are reasons a standard implementation needs added complexity (has to cover every edge case)

oaiey 5y ago
Because most original API (DOM, browser, date, etc) are OO oriented and you stick your standard library in one pattern. And speaking of everyone moving to functional programming: i work with several hundred developers in four continents in a very dynamic envirnment.... And I have not seen a FP advocate. Not that FP is not good (I prefer it where applicable) but mindset/winning/moving towards are words I would not choose when it comes to describing the state of FP and OO in the world. There is a strong influence but not to a degree where an established language changes its core paradigm: see Java, C#, JS, ...
- lnxg33k1 5y ago
  I would be more prone to say that the original API are something that came up by using buzzwords from growing languages or something else, for sure they're a thing, but like it's not that `new` makes an OOP approach if then you miss inheritance, abstraction, encapsulation and polymorphism, I'm not sure if I am being picky but like if there is just a keyword and nothing else more important to the paradigm then I think it might be confusing for some reader to see something like that statement
- jacksnipe 5y ago
  Really? I have seen — across many jobs and company sizes and frameworks, over about a decade — a slow but inexorable trend of moving toward FP. Be it in React, where hooks are pushing everything to be functional; to the fact that Monads have started showing up in unexpected places in codebases I’ve worked on; to the fundamentally functional nature of frameworks I have to use every day working at a FAANG. Along the way, until the FAANG, I never met any functional advocates. What I did meet are people who reach for the appropriate functional tools when building solutions; others see the much better solutions they arrive at, and copy.