Dates and Times in JavaScript – A New API for Dates from TC39

https://blogs.igalia.com/compilers/2020/06/23/dates-and-times-in-javascript/

by 98codes • 6 years ago

268 154 6 years ago

blogs.igalia.com

flipchart3• 6 years ago

Does this mean I can get rid of moment.js now?

SwiftyBug• 6 years ago

moment.js is so annoying because if I don't do momentObject.clone() everywhere I end up having many unwanted side-effects.

flipchart3• 6 years ago

I've been burned by this so many times! Code that uses moment is written, tested, and then never touched to make sure you stay sane

Roboprog• 6 years ago

I have been lucky, then.

I pulled in moment about 5 years ago into our group’s stack, but we mostly use it for parsing and formatting date (only) strings for date arithmetic. The government vital records forms we are working with seldom deal with time of day, and when they do, it’s an optional string down to minutes resolution only.

I guess all the converting to and from strings coincidentally protected me from mutability. Good to know.

wyattjoh• 6 years ago

I've switched most of my work that used to use moment over to Luxon[0] now. It's still written by the same authors, but fixes a lot of the drawbacks[1].

[0] https://moment.github.io/luxon/index.html [1]: https://moment.github.io/luxon/docs/manual/moment.html

flipchart3• 6 years ago

I'm using React Widgets[0] and I prefer moment over Globalize (been through so much pain with this). Maybe it's time to either write a localizer for Luxor or find a new date time picker

[0] https://jquense.github.io/react-widgets/localization/

WorldMaker5• 6 years ago

Luxon is great.

Also, if you find you only really need one or maybe two date time utilities, date-fns [1] is an alternative that that takes an even more modular approach for tinier imports.

[1] https://date-fns.org/

mattwad2• 6 years ago

I've been using date-fns on the backend. It's great; so long as you don't have to deal with timezones, because the functions only accept and return Date objects, which don't support internal timezone. The other day I needed to get the hour of day based on a user's timezone, though. And had to resort to moment-timezone because NO i dont want to have to handle the math on my own.

kcorbitt2• 6 years ago

Check out https://www.npmjs.com/package/date-fns-tz. The API is much less intuitive than the `date-fns` one because javascript Date objects don't store their timezone, but I've used it in a real project and it's workable once you grok the mental model.

jacobr2• 6 years ago

You can already use https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... for quite a few of moment’s use cases.

ryzokuken11• 6 years ago

Not yet, but fingers crossed, it would reach Stage 3 in a few months.

pininja• 6 years ago

Very excited about the timezone improvements here! Their cookbook has great examples https://tc39.es/proposal-temporal/docs/cookbook.html#preserv...

lxe• 6 years ago

You will still need libraries to do nicely formatted time strings like "next week" or "3 hours ago"

runarberg4• 6 years ago

Look at `Intl.RelativeTimeFormat`[1] and `Intl.DateTimeFormat`[2].

Regrettably Safari is—yet again—lacking with support, but in the meantime there is a polyfill.

1. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

2. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

chrismorgan2• 6 years ago

I find RelativeTimeFormat to be not as useful as it seems—it’s surprisingly limited in scope and utility. You still have to calculate the magnitude and unit of the distance (“3 hours ago” → (3, 'hour') rather than saying “here’s a Date object that happens to be about three hours in the future, you tell me what unit to show”), and it only supports one unit at a time (“1 day ago” or “27 hours ago”, not anything like “1 day, 3 hours ago”), and it can’t produce anything like “next Tuesday” or “this Friday”.

Twice I’ve started with it, twice I’ve tossed it out because in the end it didn’t help my code at all. (Both times I only cared about English, so its replacement which did a better job of formatting values for my situation took pretty much no extra code—for exact equivalence, formatter.format(-n, 'day') for known positive n becomes a simple ternary, `n == 1 ? '1 day ago' : '${n} days ago'` (or if the formatter has the {numeric: 'auto'} option, change '1 day ago' to 'yesterday'); but even with full localisation, I’d still be unlikely to use RelativeTimeFormat.)

josteink• 6 years ago

You will still need libraries to do nicely formatted time strings like "next week" or "3 hours ago"

If you want those formatted values to be consistent with the rest of your app, you will need this anyway.

You app does support localisation right?

Also: there’s no guarantee a browser would have the same localisation as your app (for instance German-language browser, English website).

You really have to do this 100% yourself in your app if you want the result to look right.

runarberg4• 6 years ago

Apps are seldomly translated into my native language, but I do have my browser configured to use my native language, so I often see date values in a different language from the rest of the app, and it doesn’t bother me at all. In fact I hardly notice it.

jacobr2• 6 years ago

You would do new Intl.DateTimeFormat(siteLocale) and not new Intl.DateTimeFormat(browserLocale) to get consistent formatting.

jasonkillian2• 6 years ago

I think this is a great proposal and a huge step in the right direction for JS. I am curious though, is there a reason not to just essentially duplicate the Joda[0]/Java[1]/ThreeTen[2] API? As far as I understand, they are generally considered a gold standard as far as datetime APIs.

Is it too Java-y that it wouldn't make sense to port to JS? Are there copyright implications?

The JS Temporal proposal _does_ as far as I can tell, share many of the underlying fundamental concepts, which is great, but then confusingly has some types, such as `LocalDateTime`, which mean the exact opposite of what they do in the well-known Java API [3].

There is still discussion going on about these details, but from my perspective it seems like the best thing would be to just copy the Java naming conventions exactly.

[0] https://www.joda.org/joda-time/

[1] https://docs.oracle.com/javase/8/docs/api/java/time/package-...

[2] https://www.threeten.org/

[3] https://github.com/tc39/proposal-temporal/issues/707

Ndymium• 6 years ago

The JS Temporal proposal _does_ as far as I can tell, share many of the underlying fundamental concepts, which is great, but then confusingly has some types, such as `LocalDateTime`

I can't find a mention of LocalDateTime in the Temporal docs, did you mean something else?

leothekim3• 6 years ago

I think he's referring to https://github.com/tc39/proposal-temporal/issues/707.

jasonkillian2• 6 years ago

It's a current WIP idea for the spec: https://github.com/tc39/proposal-temporal/pull/700

Figuring out a name is still part of the ongoing discussion, so this specific case of `LocalDateTime` isn't a huge deal, and I might have misrepresented things slightly in my original comment, sorry! But I do think the overall point still stands - that it might be best to just use the same names and terminology as Java does.

leothekim3• 6 years ago

+1 to going off of Joda API. This is a very well-thought out datetime API with a fluent interface for building date/time objects in an immutable way. Just doing this would be a huge step improvement for JS.

bxparks• 6 years ago

I find that the Java 8 java.time API [1] easier to understand than Joda Time [2] when working with timezones. In particular, the OffsetDateTime and ZonedDateTime classes in java.time seem well-designed and easy to use. The equivalents in Joda Time are harder for me.

[1] https://docs.oracle.com/javase/8/docs/api/java/time/package-...

[2] https://www.joda.org/joda-time/apidocs/index.html

TheCoelacanth• 6 years ago

This. They already copied the crappy date API from Java. Why not copy the good one too?

eropple2• 6 years ago

I don't usually laugh at HN comments, but this is pretty good. And it's true. Joda-Time and its near relatives are just genuinely good. So much effort has gone into addressing so many edge and corner cases that it seems like a shame to not just tuck all that work under one's arm and steal it.

needusername2• 6 years ago

I assume it doesn't help that Oracle is arguing in court that APIs should be copyrightable.

ryzokuken11• 6 years ago

I am curious though, is there a reason not to just essentially duplicate the Joda[0]/Java[1]/ThreeTen[2] API?

They're definitely an influence, just not the only one.

LocalDateTime

That's a strawman proposal that's essentially user feedback and not a part of the API. Not yet atleast.

salmonellaeater• 6 years ago

There is already a JS port of Joda[1] which works well and, crucially, uses all the same names and concepts. Could we just replace the Temporal proposal with this and save a lot of work and confusion?

[1] https://js-joda.github.io/js-joda/

benatkin2• 6 years ago

Joda Time, like Python's datetime and a lot of other date/time libraries, has a date/time class that includes a timezone. Temporal keeps that separate. I think it's a different enough design that Joda Time's popularity isn't enough of a justification for adopting its API.

stickfigure• 6 years ago

It has a date/time class that doesn't include a timezone too...

needusername2• 6 years ago

Well they actively ignored his input:

https://github.com/tc39/proposal-temporal/issues/7

https://github.com/tc39/proposal-temporal/issues/84#issuecom...

oefrha• 6 years ago

TL;DR:

Actual spec: https://tc39.es/proposal-temporal/

Less formal docs: https://tc39.es/proposal-temporal/docs/

Examples: https://tc39.es/proposal-temporal/docs/cookbook.html

You can try Temporal in the JS console on a doc page.

leothekim3• 6 years ago

So glad to read that the core objects are immutable. This is probably my biggest gripe of other date/time manipulation libraries, eg moment.js.

kcorbitt2• 6 years ago

https://date-fns.org/ is the most popular alternative to moment-js, has an intuitive functional API and treats dates as immutable. I migrate every project I touch over to it since it has so many fewer footguns.

eropple2• 6 years ago

Huh - thanks for the link. The Moment folks also have Luxon, which I've been using, but there's quite a lot more momentum behind date-fns.

erichurkman• 6 years ago

+1 for date-fns. It's not uncommon to look at a downloads in a JavaScript bundle to find out Moment — and its timezone and localization files — are a huge percentage of a download for a single `moment.format()` call.

pyrhho• 6 years ago

I wanted to use date-fns on the current project. But, the gotcha is due to its lack of timezone support many of its functions are inherently broken (e.g. startOfWeek). So, if you need rich calculations with timezone support watch out!

tzs5• 6 years ago

I'd like to see the JavaScript people, the Java people, the PHP people, the Perl people, the Python people, the C people, the C++ people, and the people for every other significant language that supports functions (either directly or as methods on objects) to get together and once and for all agree on how the heck we are supposed to deal with times and dates.

Then all of them should implement that in their standard library, so that going forward we've got one sane conceptual time handling system everywhere.

I tire of dealing with the quirks of everyone having their own approach.

G4BB3R• 6 years ago

Community driven libraries APIs are a mess, look at React Native or Js in general. I'd rather a (group of) specialist to develop the API.

tzs5• 6 years ago

Sorry for not being clearer. By "JavaScript people", "Java People", etc., I didn't mean the communities. I meant the people who make the standards for those languages.

mattwad2• 6 years ago

It's not just that. Timezones are the real bugger. Microsoft has their own list of names separate from the standard IANA timezones, for example. If it weren't for timezones, IMO dates are pretty damn trivial. It's just a matter of storing and transferring them properly (in UTC, always!)

frenchyatwork• 6 years ago

Timestamps are damn trivial. When people use dates, that's all they want 90% of the time. The remaining 10% is where all the hard problems are.

For example, lets say I have a store that opens from 8:00-17:00 every day, and it's currently 22:00. How long is it till it opens next?

1-more• 6 years ago

There is a case to not store a time in UTC: you schedule a meeting in the future and the local authorities change when they start DST in that location. Now your user gets the alert an hour too early or late for their meeting. The scenario is more fleshed out in the link below but I don't want to just copy and paste the article into the comment.

http://www.creativedeletion.com/2015/03/19/persisting_future...

deathanatos2• 6 years ago

in UTC, always!

… which the proposal doesn't use. (It uses POSIX.)

tigershark2• 6 years ago

No they are absolutely not. Ask Jon Skeet for example:

https://codeblog.jonskeet.uk/2010/12/01/the-joys-of-date-tim...

https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a...

Or look at the usual falsehood list:

https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b...

Some interesting ones:

A week (or a month) always begins and ends in the same year.

Months have either 28, 29, 30, or 31 days.

There is a leap year every year divisible by 4.

The day before Saturday is always Friday.

hart_russell• 6 years ago

I have worked on a DoD program that dealt with time precision. It is not a trivial task let me assure you.

lmkg• 6 years ago

Basically we need Unicode But For Time.

These are similar problems: getting a computer-amenable model of something that's fundamentally a human phenomenon, and carries multiple centuries and multiple continents of accumulated context, ambiguity, and edge-cases. This is an extremely difficult class of problems, but in the case of text & characters, we managed to finally get a pretty well-functioning and broadly-supported solution after a few decades of gratuitously-incompatible half-solutions. There's hope.

WorldMaker5• 6 years ago

Almost everything should be capable of parsing and outputting ISO 8601 dates [1] today. About the biggest recommendation that still seems to lacking in documentation is that you should probably consider offsets (Z or -0500 etc) required rather than "optional", and that you have to remember that offsets are not timezones (and that generally you should store offsets as presented rather than convert between offsets; makes it easier to adjust offsets based on timezones).

[1] https://en.wikipedia.org/wiki/ISO_8601

klodolph• 6 years ago

We have “Unitime”, in a sense, because we have RFC3339 and ISO-8601. What we don’t have are good date time handling in standard libraries.

In spite of Unicode we also have a bunch of programs and libraries that mangle text.

pjmlp• 6 years ago

They are yet to agree how to deal with strings, how do you expect them to agree with time and dates?

hyperpape2• 6 years ago

I'm not sure strings are easier. When to use mutable vs. immutable strings has a significant performance impact, how do you manage memory for them (including when do you copy strings vs work with a slice) are all questions where there's at least 3-4 distinct designs that you might want (a C like language, a C++-like language, a Rust-like language, and a GC'd language).

In contrast, for dates and times, everyone really could have used the same design. Maybe you'd need a slightly different design for dynamic languages, but I'm not even sure about that.

ProZsolt• 6 years ago

Tom Scott has a great video about time and timezones on Computerphile: https://youtu.be/-5wpm-gesOY

cactus2093• 6 years ago

I don't think it's actually that important that every language deals with them the exact same way. I interpret that to mean they all translate the APIs as literally as possible between them, using the same method names, same types of arguments, etc. Different languages all have their own quirks and patterns and it's also useful that the library be idiomatic within the language.

Most of the problems I have seen in dealing with time, across various languages, arise from allowing types to be way too ambiguous. A lot of code uses interchangeably things like "UTC -0700" and "America/Los_Angeles" which are actually very different (one incorporates daylight savings and one doesn't). The important fix is that languages start using reasonable abstractions and are stricter about requiring explicit conversions between types rather than trying to implicitly guess an interpretation.

The first library I've seen get this right was Joda in Java, and it later got included into the standard library for Java. It's been copied other languages, and I've used it on the frontend a bit as JSJoda, but the literal translation makes it a bit awkward in JS and I found it was hard to get other JS developers to prefer it over the more popular moment or date-fns. Temporal looks great, it actually seems to borrow heavily from Joda but doesn't literally copy all of the names or methods so hopefully it will be the best of both worlds.

temporallobe• 6 years ago

Maybe I’m stating the obvious here, but there is actually a standard: ISO 8601. Vendors however don’t seem to follow this, either consistently or at all. As for a standard library, Javascript doesn’t have one - everything is built into the core language. Also, fundamental differences between language syntaxes could have a huge impact on usage and implementation. So even if every existing and future language on the planet followed ISO 8601, there would always be that language barrier.

sratner5• 6 years ago

ISO8601 is a representation standard, not a standard for abstract concepts.

https://news.ycombinator.com/item?id=23783603 called for Unicode but for Time, which I think is perfect. In that framing, ISO8601 is UTF-8, but it is Unicode that is needed for everyone to agree on what is "code point" and what is a "character" (equivalently, what is a "calendar date", what is an "absolute timestamp", etc).

tzs5• 6 years ago

I don't expect that the usage and implementation would be the same in all languages. Just that they would at a high level have the same representations and provide the same operations.

For example, if the standard was that a datetime would be represented as separate year, month, day, hour, minute, second, time zone some languages might implement that as a struct with names fields for each of those 7 elements.

Some languages might implement it as an object with properties for each of those elements.

Some might implement it as an array with one entry for each of those elements.

If the standard called for a function add_seconds that adds a given number of seconds to a datetime, modifying that datetime in place, languages that use a datetime struct might provide a standalone function that takes a pointer to a datetime struct and the number of seconds to add.

Languages that represent datetime as an object might have add_seconds as a member function.

So if I'm a Perl programmer and know how this standard works in Perl that would not necessarily mean it is obvious to me how it works in Python or C. But it would mean I could think about time the same way in all of them. I could expect to have corresponding data structures in all of them, with the same core set of operations available in all of them.

Names might be slightly different (e.g., what the standard calls add_seconds might become addSeconds in a language that by convention uses camel case for member function names), but the point is what these functions and data structures actually do would be standardized so once I know how to do all my date and time stuff following this standard it is easy to map that to the language specific implementations in JavaScript, Java, PHP, C, and the rest.

russellbeattie• 6 years ago

Your proposal might seem crazy, but we've actually been able to do this before. While learning WebXR not long ago and looking for examples, I discovered it was based on OpenXR (1) and literally every big tech company has APIs that were similar - I ended up reading docs and sample code from Android, C#, and even Apple to get a better idea of how things were wired together. It was a very pleasant surprise!!

1) https://en.m.wikipedia.org/wiki/OpenXR

niftich• 6 years ago

This basically exists, and it's called ISO 8601. But the scope of ISO 8601 isn't programming languages and APIs, but data models and their representations. A subset of ISO 8601 forms the basis of RFC 3339. Official copies of ISO 8601 are available for a fee from ISO. For the purposes of this discussion thread, consult this file hosted by the US Library of Congress for reference [1].

ISO 8601 defines a number of terms of art to represent a thorough mental model of the problem space, and then goes on to define string representations on how to express them. But it's paywalled, so people reach for RFC 3339 and the Wikipedia article instead. These focus on representations, and the definition of the concepts isn't captured clearly, so sometimes they're rediscovered independently. Other times, they're not.

Serious attempts to figure this out usually coalesce to something that looks and behaves like Java 8 time. Java 8 time may be verbose, but its concepts are clearly mapped out, and the API bears some marks of a misuse-resistant design. Compared to that, there's efforts like the standard libs for Python, Ruby, Go, or most third-party libs for JS, Rust, that don't bring clarity to the table, and don't present any solution for dealing with calendrical or clock-face objects, and do little to discourage misuse of their point-in-time objects in abstract contexts.

This proposal falls much, much closer to the Java 8 way than to the "everything is an instant, go make your own classes" way.

One shortcoming of ISO 8601 is that it has no provisions for abstract timezones. Instead, people go outside of the standard to represent ISO datetimes alongside IANA timezones.

But the most glaring problem with ISO 8601 is that it doesn't define partials where a more-significant term is unknown or missing: there's no valid, unambiguous way to refer to the 15th day of March, while leaving the year deliberately unspecified. This means that anniversary dates (e.g birthdays, holidays) aren't possible to represent in the abstract.

Likewise, there's no valid, unambiguous way to refer to the 29th second of the fourth minute of every hour. This is much less important than the birthday shortcoming.

The Library of Congress has a standard which extends ISO 8601 with a number of useful constructs for their purposes [2], like uncertainty qualifiers, but even that standard has no mechanism to represent a month+day partial in the abstract.

[1] https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0038_i... [2] https://www.loc.gov/standards/datetime/

simon042• 6 years ago

to refer to the 15th day of March, while leaving the year deliberately unspecified

Quoting from https://en.wikipedia.org/wiki/ISO_8601#Calendar_dates –

The 2000 [of ISO 8601] version allowed writing "--04-05" to mean "April 5" but the 2004 version does not allow omitting the year when a month is present.

mrlala3• 6 years ago

I can't speak for every language you listed, but C# has great and clear datetime builtin.

Probably the only thing perhaps not the most standard are the names they use for actual time zones? So perhaps that could be improved.

But seriously I don't know how the fuck javascript people can work with dates. It's ATROCIOUS. I think my favorite one is 0 indexes on months? like if you do date(2020,07,09).. is that July 9th 2020? nope, fucking June! Not June 8th.. but June 9th.

I don't know what monster did that but there should be a special place in coding hell for him/her!

dmurray• 6 years ago

How does that work? Do you really mean it's August 9?

tzs5• 6 years ago

I believe that the logic behind 0 based months in many languages that use them, although I don’t know if this is true for JavaScript, is that month numbers are often used as an index into a table of month names so numbering months from 0 is convenient.

galvin• 6 years ago

Regarding JavaScript, either you avoid manipulating dates and just pass them to the server in ISO format, or you use a library like Moment.js.

The native API's are a disaster and using them is just asking for trouble!

balfirevic2• 6 years ago

I can't speak for every language you listed, but C# has great and clear datetime builtin.

If you think built-in .NET DateTime is any good, give NodaTime a try. Standard DateTime is barely usable, compared to it.

For JavaScript, there is excellent js-joda library (same design as NodaTime and Joda-Time), but it's 43 kB minified and compressed, which is... not terrible but also not great, really depends on your use case if it's worth it.

duxup• 6 years ago

Yeah I don't care what the solution is.... if everyone just does it, that would be great.

Then I'll care / complain about the solution ;)

ryzokuken11• 6 years ago

Temporal does in fact conform to standards like ISO 8601 for serialization/parsing etc.

ralmidani• 6 years ago

I agree in principle, but achieving that kind of harmony between languages is analogous to the world‘s governments agreeing to “save succeeding generations from the scourge of war”. That sounds like an exaggeration, but even if language maintainers are all enlightened enough to compromise, the communities are not necessarily going to comply. The minute a language changes how it deals with dates and times, it’s more than likely someone will, very loudly, announce their intent to fork it in order to preserve the old way of doing things.

beached_whale• 6 years ago

The C++ model is very nice to work with. C++20 will be even better as Howard Hinnant's Date library has been incorporated.

smichel172• 6 years ago

Later: https://xkcd.com/927/

faitswulff2• 6 years ago

Random question, but how does time work if your box is on, say, Mars?

techdragon• 6 years ago

There’s a history of using local Martian solar time in the past, driven by the need to operate in the Martian daytime for rover safety. They even made special watches that ran “slow” compared to earth times so that they kept correct Martian solar time for some of the missions.

However for “absolute” chronological records you would be looking at using Barycentric Coordinate Time, which is what we get when we do a bunch of corrections to subtract the effects of the sun and earth’s (and the other planets) mass and motion, leaving us with a virtual “clock” that is suitably common for anything in the solar system.

To quote one definition of Barycentric Coordinate Time - ”It is equivalent to the proper time experienced by a clock at rest in a coordinate frame co-moving with the barycentre of the Solar System: that is, a clock that performs exactly the same movements as the Solar system but is outside the system’s gravity well.”

The ELI5 I normally use is roughly: It’s what we get if we take the Solar System in its normal orbit around the Milky Way, with some fancy magic we subtract away all the stuff, sun, planets, moons and all the asteroids and comets we can count, and then with a little more fancy magic, we put a super accurate clock that doesn’t weigh anything at all back at the center of where all the solar system stuff used to be.”

lowwave• 6 years ago

Technically, Javascript is a standard. By Ecma International: https://www.ecma-international.org

d0mine• 6 years ago

There is no approach that works for all use-cases when you are dealing with time (there are only various trade-offs).

There is the tz database that is correct for many use cases. It should be available in all languages that you listed https://en.wikipedia.org/wiki/Tz_database

nerf0• 6 years ago

So much this. Not to mention that even within the same language, the implementation can differ (e.g. Firefox vs Chrome).

I recently had to parse a bunch of dates in python, writing them to postgres, and then handle the same dates in javascript. And boy was it a PITA. The worst problem was the handling of "BC" dates. I had to hack my way around the boundary between python and sql. Javascript is no better, it simply doesn't compute BC dates without heavy hackery.

ABoldGambit• 6 years ago

Great proposal, but Temporal is a poor name. Why not, in the age of the import keyword, finally just have a standard library, and import Date from std like a proper programming language?

politelemon• 6 years ago

I agree, I think there should have been some drop-in replacement which would allow old scripts to continue working but also let new work make use of these improvements with `Date`. I feel that this duality will persist for a long time, and it can lead to answers, documentation and codebases becoming a confusing mess. It's hard to predict exactly what this mess will look like, only... er... Time will tell.

runarberg4• 6 years ago

There is a proposal for that[1] which introduces a `js:` pseudo-protocol for importing a build in module (or a standard library):

    import Temporal from "js:temporal";

1: https://github.com/tc39/proposal-built-in-modules

hyperpape2• 6 years ago

I agree Temporal is an odd name for the object representing an Instant. But it shouldn't be Date either. A Date does not have a time associated with it.

Java really did a good job here: Instant, LocalDate, LocalDateTime, ZonedDateTime. (If they hadn't already had java.util.Date, they probably could've replaced LocalDate/LocalDateTime with Date/DateTime, but that ship sailed).

cwp• 6 years ago

Temporal is just the namespace. It has classes called DateTime, Date, Time, TimeZone, Duration etc.

renw0rp• 6 years ago

And people used to complain about Java development being slow and behind other languages...

Regarding JavaScript temporals - better late than never I guess.

ryzokuken11• 6 years ago

It's been WIP for a few years now! It's easily one of the largest changes to the stdlib of JavaScript recently, and things like these take forever to standardize.

miltonlaxer• 6 years ago

Just gimme epoch time and we're good.

ryzokuken11• 6 years ago

Temporal.now.absolute().getEpochNanoseconds()

theandrewbailey• 6 years ago

In Planck time.

moralestapia• 6 years ago

A comment on the side,

JavaScript Date is broken in ways that cannot be fixed without breaking the web.

I really dislike the arrogant tone that many "new" people employ when talking about some "old" thing they are trying to "improve". (Quotes are there to indicate sarcasm).

Date is not 'broken', it may just not do whatever the author wishes it did; it is not 'broken' in the sense of failing to perform its intended function adequately.

I hope people could change their ways and be a bit more decent in general.

Aside from that, I welcome the new API as I think it would be an improvement over what we have now.

Spivak• 6 years ago

I think https://maggiepint.com/2017/04/09/fixing-javascript-date-get... and https://maggiepint.com/2017/04/11/fixing-javascript-date-web... are better links for the motivations of what parts of Date can't be fixed without needing a new API.

ryzokuken11• 6 years ago

Date is "broken" in that it aged pretty poorly, has a very non-ideal API surface and exposes developers to a number of footguns, that could, ideally, be avoided.

The fact that a vanishingly small percentage of JavaScript developers use Date for non-trivial applications is a great indicator of these failures.

swrobel• 6 years ago

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

himinlomax• 6 years ago

Will it allow for using TAI?

ryzokuken11• 6 years ago

Not the core API, but a simple custom timezone can be used to implement TAI. I worked on a POC for it, but you can totally test this with the polyfill right now.

https://github.com/ryzokuken/temporal-tai

deathanatos2• 6 years ago

Kind of, but not really? The proposal's Absolute represents time in the POSIX timescale, so it is inherently incapable of representing all of TAI, the same as it is inherently incapable of representing UTC.

I attempted to test your library's behavior in this regard, but I do not think you are correctly implementing the proposal's TimeZone. TimeZone.getDateTimeFor() is supposed to take an Absolute and return, in your case, the time that absolute represents in TAI (that time, in the TimeZone). But this:

  var one_before = new Temporal.Absolute(915148799n * 1000000000n);
  console.log(one_before.toString());
  console.log((new Temporal.TimeZone('UTC')).getDateTimeFor(one_before).toString());
  console.log((new TAI()).getDateTimeFor(one_before).toString());

emits,

  1998-12-31T23:59:59Z
  1998-12-31T23:59:59
  1970-01-01T00:15:15.148768

That last timestamp being the output supposedly in TAI; but that POSIX timestamp, 915148799 represents 1999-01-01T00:00:30 in TAI. That is, the second line, 1998-12-31T23:59:59 in UTC == 1999-01-01T00:00:30 TAI.

The other direction (getPossibleAbsolutes) is similarly effected.

sunseb• 6 years ago

Why not using a namespace like stdlib/datetime instead of this weird named Temporal thing?

ryzokuken11• 6 years ago

because Temporal is not currently used anywhere (as far as we noticed) and it won't break anything while still being descriptive.

petepete• 6 years ago

So long as months are indexed by 1 I'm all for it.

ryzokuken11• 6 years ago

They are!

tlhunter• 6 years ago

I'm excited to see this land in Node.js! Currently there are only hacky solutions for calculating nanosecond-accuracy wall clock time.

jeffmcmahan• 6 years ago

This is one of those glaring problems that somehow was passed over the last 10 times people got together to decide to improve JS. Remarkable that it has taken so long.

chaostheory• 6 years ago

It's probably due to Javascript having such a giant ecosystem. I feel that moment and date-fns dull the pain so much that most people just don't care. Otherwise, this would have been solved faster.

ryzokuken11• 6 years ago

It's been WIP for years now. Just takes a lot of time to standardize something like this, you know...

LittleDan• 6 years ago

It would be great to hear feedback from everyone on the Temporal survey: https://forms.gle/iL9iZg7Y9LvH41Nv8

noiv2• 6 years ago

Asking for uni-time ignores physics. It just doesn't exist. It can already be measured clocks separated by a meter in altitude run differently. We might have something that works for daily human stuff, but if you leave the planet or ask for Pico seconds, no standard can help...

vore• 6 years ago

Anyone doing specialized calculations with time at that level of precision is going to be using specialized code and not any built-in time handling code.

noiv2• 6 years ago

That just proves my point, uni-time is a dead end.

SigmundA• 6 years ago

So can I round trip it to JSON yet, no, bummer...

chrismorgan2• 6 years ago

JSON has a deliberately limited vocabulary, and is never going to be extended. Objects, arrays, strings, numbers, booleans and null, that’s all you’re ever going to get.

benatkin2• 6 years ago

I think it's quite nice! It tries to be as unopinionated as possible, and does a good job at it.

jchook• 6 years ago

Reminds me of the incredible Time on Unix[1] article.

1. https://venam.nixers.net/blog/unix/2020/05/02/time-on-unix.h...

typescriptfan1• 6 years ago

Date is actually pretty good.

* If you're reading UTC dates from the backend and displaying them in local time, new Date(year + 1900, month, day, hour, minute, second) works great.

* It's also easy to calculate repeating intervals in local time by using that constructor with getYear(), getMonth(), etc.

* Send it back to the server with .toISOString(). Add a .replace('Z', '') on that so .NET binds a DateTime with the right Kind.

Dates and Times in JavaScript – A New API for Dates from TC39

Related Stories