19 ms·
Temporal: Getting started with JavaScript's new date time API
- CA0DA 5y ago"January is month 1" This is what we were all waiting for.
- IshKebab 5y agoWere we? Would have made more sense to change the day-of-month to be zero based too IMO. Or explicitly have both: `monthOne` and `monthZero`.
- tffgg 5y agoWhy would you want that? It is super confusing since 1~first as well as every real life date representation I know has 1=January
- globular-toast 5y agoBecause it only needs to be "1" when you format it for human consumption. 0-based is much easier to work with internally.
- lexicality 5y ago> 0-based is much easier to work with internally. Why's that?
- petepete 5y agoEven if it was I'd still want days and months to start at one and, you know, match everything else in existence that represents them.
- globular-toast 5y agoMainly because you can use normal modulo arithmetic and use them as array indices. But as I mentioned in another comment, really you should be touching the internals of the datetime object at all. It's a mistake to do something like `myDatetime.day += 1`. You should instead do `myDatetime + timeDelta(days=1)` or something. So it shouldn't matter whether it's 0-based or 1-based at all. But since it apparently does (I don't know why), then it might as well by 0-based like everything else.
- cunthorpe 5y agoNo it doesn’t. Dates aren’t meant to be worked with as raw numbers, so the utility of 0-based numbers is gone and now you only have February ending on day number 27
- globular-toast 5y agoIf people don't work with them as numbers then the argument is completely moot. All you need is timestamps, deltas and formatting functions. How many days is in the delta 1 hour? 1? or 0?
- IshKebab 5y agoThe whole reason months start at zero is because somebody wanted to work with them as raw numbers.
- cunthorpe 5y agoYes and they were wrong. There’s a whole “misconceptions programmers have about dates” you might want to read. The only number for dates is the Unix timestamp.
- globular-toast 5y agoSo if I want to have a style per month or something in my program, I'm wrong? If I want to select the next month's style I have to do something awkward like `(current mod 12) + 1` instead of the more natural `(current + 1) mod 12`?
- dspillett 5y agoThen why do days not start from 0. If that argument is value it should be applied consistently so 2000-01-01 is day=0, month=0.
- globular-toast 5y agoProbably because the ancients didn't have a strong grasp on the number 0. Midnight is zero. What's confusing about the number of days starting from 0 too? Why do we use months? No sane internal representation stores the number of months. They are completely and utterly useless and exist only in printed representations of dates.
- jcranmer 5y agoProps to the Mayans, whose dates are (almost) a base-20 number counting from the Mayan date of creation. It's not fully base 20, because the 2nd digit only counts to 18 because 360 is close enough to a year. So 13.0.5.17.19 is followed by 13.0.6.0.0 instead of 13.0.5.18.0. Bonus points: no leap years to worry about! The downside is that their full calendar is somewhat more complicated, so they would say that today is (checks) 13.0.8.11.11 8 Chuwin 9 Sek, and tomorrow is 13.0.8.11.12 9 Eb' 10 Sek (that Tzolkin calendar component doesn't work like our months do!).
- dspillett 5y agoI was meaning in the context of JavaScript, where the first day is 1 and the first month is 0. A case can be made for either 0 (for consistency with time representation) or 1 (to go with the defacto standard of how most if us bipedal meatsacks process dates) but there must have been alcohol or something stronger involved when the current date object came into being.
- globular-toast 5y agoErm... nobody was arguing for it being the current way. That's retarded. This whole thread is about making them both 0-based rather than both 1-based.
- 5y ago
- edoceo 5y agoISO 8601 says January is 1. We have a standard.
- globular-toast 5y agoISO 8601 is a serialisation format. What's your point?
- squeaky-clean 5y agoWhat is "January" -> "1" if not serialization?
- edoceo 5y agoPoint is: there is a standard. Use it.
- globular-toast 5y agoAre you suggesting JS printed "ISO 8601" strings with 0-based months before now? Do people really not know the difference between internal representation and serialisation? Are we even speaking the same language? Truly baffled by this.
- rhacker 5y agoWhat is Monday and Sunday? edit: The dayOfWeek read-only property gives the weekday number that the date falls on. For the ISO 8601 calendar, the weekday number is defined as in the ISO 8601 standard: a value between 1 and 7, inclusive, with Monday being 1, and Sunday 7. For an overview, see ISO 8601 on Wikipedia.
- filoeleven 5y agoThey had me at “all objects are immutable.” They lost me at “ date time values without time zones.” I’m mostly kidding with the second line. Working with third-party React calendar components requires doing some moment.js math and then hacking off the last few characters of the .toISOString() to make the calendar happy. So I can see how it’s a very practical addition. Please don’t misuse it.
- below43 5y agoThey lost me at “ date time values without time zones.” This is rather useful for date of birth, which shouldn't be set to a time zone in most use cases (it can get rather confusing if you do).
- filoeleven 5y agoEvery DOB field I’ve seen is just a date, with no timestamp at all.
- stevula 5y agoThere’s a footgun when you convert DOBs to Date objects. This can return different dates depending on the local timezone: ``` new Date("1/1/2021").toLocaleDateString() ``` If you want it to return the same DOB regardless of local timezone, you have to pass a timezone to the Date constructor, which is not super obvious. This kind of bug is also unlikely to get caught by unit tests unless you’re testing date formatting for different timezones, which you probably wouldn’t do if you’re not aware of the footgun to begin with.
- raxxorrax 5y agoDidn't find to much info on arithmetic support, although it is mentioned. However, I hate working with dates because many APIs make question about dates a slog. Consider the following for the poor people on the dark side of the planet (UTC + something). If any application only saves the date and not the time and you have dates like 2021-06-28T00:00:00 or something like that. Now it gets saved in a DB as 2021-06-27Z23:00:00, because the user lives in UTC+1-land. It is correct but makes my blood boil and propably causes a lot of errors, even in apps that set their time zone correctly. How often have I seen implementations that just /(.*)T.*/ match the date and create a bug. I have no solution for this, but I wasted too much time on problems like this. Such errors also notoriously evade unit tests... This seems decent from a quick look. But let us be honest, it has to compete with moment.js, not with Date().
- rauschma 5y agoThe Temporal cookbook has more information on time arithmetic: https://tc39.es/proposal-temporal/docs/cookbook.html#arithmetic https://tc39.es/proposal-temporal/docs/cookbook.html#arithme...
- raxxorrax 5y agoThat looks very promising, thank you.
- rendall 5y ago> But let us be honest, it has to compete with moment.js, not with Date(). Moment.js is deprecated: "Moment.js is a legacy project, now in maintenance mode. In most cases, you should choose a different library." https://github.com/moment/moment/#project-status https://github.com/moment/moment/#project-status
- raxxorrax 5y agoTrue, but I think it will be some death of author kind of story. Nevertheless the handling has to be at least on a similar level.
- 5y ago
- vbezhenar 5y agoJava 8 Date/Time API is surprisingly nice. I think that every language should just copy it. It's comprehensive and easy to use.
- twic 5y agoJava 8's time package is a sort of second version of Joda-Time by Stephen Colebourne, who is not very impressed by the new JavaScript API: https://twitter.com/jodastephen/status/1393146501073973248 https://twitter.com/jodastephen/status/1393146501073973248 He has opened a few issues along the way, trying to help TC39 learn from Joda's experience, with varying results: https://github.com/tc39/proposal-temporal/issues?q=is%3Aissue+author%3A%22jodastephen%22 https://github.com/tc39/proposal-temporal/issues?q=is%3Aissu...
- topspin 5y agoHard won lessons have to be relearned over and over in software.
- nobleach 5y agoAnd those of us who used Joda-Time were so pleased when it became almost a "built-in" in Java 8.
- lifthrasiir 5y agoOh, so the embedded calendar system in Joda-Time is a mistake. I too disliked that choice and wondered if it only exists for localization uses (but then I'd like to have a separate set of "display" classes), and well, he knew (or came to know) it. I'm relieved now.
- Vinnl 5y agoDamn, he says [1]: > Sorry to be blunt, but the current approach really is a terrible one. That is blunt, and would require my utmost restraint to avoid falling into the trap of getting overly defensive if I were the proposal authors. Which is a shame, because he makes a good point. That said, it is also reassuring to see that they did actually consider his point, and I can follow their motivation [2]. I'm not sure whether I'd have made the same decision, but it's certainly a valid one to make. [1] https://github.com/tc39/proposal-temporal/issues/1454 https://github.com/tc39/proposal-temporal/issues/1454 [2] https://tc39.es/proposal-temporal/docs/calendar-review#why-are-calendars-a-higher-priority-for-ecmascript-vs-other-platforms https://tc39.es/proposal-temporal/docs/calendar-review#why-a...
- alisiddiq 5y agoWorking with datetimes on JS for the first time was mind boggling. Few highlights: - Months start at 0 - Converting from string datetime to a datetime object will automatically convert the time to the local tz
- k1t 5y ago> Converting from string datetime to a datetime object will automatically convert the time to the local tz This happens in C# too: DateTime.Parse("2021-06-28T12:00:00Z").Hour Outputs 5 instead of 12 (for me, US Pacific) due to a default conversion to local time. It does have an opt-in flag to "adjust to UTC" though. Not intuitive at all, at least to me...
- dpwm 5y ago[EDIT] Realised this is the behavior I would expect. Parse is doing what I would expect it to, taking into account the given time being UTC. It's then returning an object that's in the local timezone. Still goes to show just how confusing this datetime stuff can be when even the expected behavior looks wrong. Wait… how is this not a bug according to both Microsoft's own spec[0] and ISO 8601[1]? The Z specifically means this time is in UTC. The behavior is not at all what I would expect from reading the docs [0]: > A string that includes time zone information and conforms to ISO 8601. In the following examples, the first string designates Coordinated Universal Time (UTC), and the second designates the time in a time zone that's seven hours earlier than UTC: > "2008-11-01T19:35:00.0000000Z" > "2008-11-01T19:35:00.0000000-07:00" [EDIT] I get it now: it's parsing it right, it's just that it's then putting it into a datetime object that's in the local timezone – which is what I would expect. The alternative would be counterintuitive to me. [0] https://docs.microsoft.com/en-us/dotnet/api/system.datetime.parse?view=net-5.0#the-string-to-parse https://docs.microsoft.com/en-us/dotnet/api/system.datetime.... [1] https://en.wikipedia.org/wiki/ISO_8601#Coordinated_Universal_Time_(UTC) https://en.wikipedia.org/wiki/ISO_8601#Coordinated_Universal...
- anamexis 5y agoThat is describing the different formats it will accept. Further down the page: > If s contains time zone information, this method returns a DateTime value whose Kind property is DateTimeKind.Local and converts the date and time in s to local time. Otherwise, it performs no time zone conversion and returns a DateTime value whose Kind property is DateTimeKind.Unspecified.
- snemvalts 5y agoThe name for the variable is kind of weird, it feels a bit like Java (having 25 years of history to account for). I wonder what the Kotlin for JS will be.
- recursive 5y agoThat was coffeescript, but it's come and gone already.
- nobleach 5y agoI'd put coffeescript as the "Groovy" of JavaScript. Kotlin is more like a mixture of Typescript and/or Reason (or whatever the name is now) Groovy was that flash-in-the pan idea that had some really cool ideas. But then again, I'm not sure if it really inspired any real language changes to Java like Kotlin has. CoffeeScript did a TON of inspiration for ES6... so heck, maybe Kotlin IS the CoffeeScript I hope Kotlin survives though.
- chaz6 5y agoIt is disappointing to see GMT conflated with UTC. It is not "UTC plus zero hours". GMT is based on solar time, wheras UTC is based on TAI. UTC is TAI corrected (with leap seconds) to match GMT. Hopefully I have got that right.
- deleted 5y ago[deleted]
- jonny_eh 5y ago> UTC is based on TAI What is TAI?
- mburns 5y agohttps://www.fhs.swiss/eng/gmt-utc-tai.html https://www.fhs.swiss/eng/gmt-utc-tai.html
- LegionMammal978 5y agoTAI is International Atomic Time. It is used as the reference point for UTC, which is defined as TAI minus a fixed number of seconds (currently 37). To add or remove a leap second, the TAI - UTC offset is adjusted. Leap seconds have no effect on TAI itself, which always runs at 1 second per SI second, as measured by a consensus of atomic clocks.
- kemitche 5y agoFor any readers who, like me, weren't sure of the differences (or what "TAI" refers to), this page helped clear things up for me: https://www.nist.gov/pml/time-and-frequency-division/nist-time-frequently-asked-questions-faq https://www.nist.gov/pml/time-and-frequency-division/nist-ti...
- HatchedLake721 5y agoThank you. I really don’t understand people who use rare acronyms on a global forum and don’t write what it is.
- 5y ago
- mellavora 5y agomandatory link: https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b... Falsehoods programmers believe about time
- ryanmarsh 5y agoI've been using Temporal in production for a few months now. I really enjoy using it. Use it mostly for creating ISO date strings and translating between timezones. I can't wait for it to make it through the TC39 process.
- chadlavi 5y agoThis plus Safari desktop support for html5 date and datetime inputs will mean that soon date input and handling will be a lot less of a pain in the ass. I'm jealous of the young devs who will never even know how stupid js dates used to be.
- deleted 5y ago[deleted]
- willio58 5y agoMy team just implemented the native date inputs for a client's site this past week. With native date inputs working for every good browser but safari desktop (it's in technology preview), we saved lots of time and effort with minimal styling of the native date input. Plus, it works soooo much better on iOS, the interface for date inputs is great. I assume it's similar on Android these days.
- chadlavi 5y agoYes! I can't wait until enough people are using the version of Safari that has html5 date input support. We have a big dumb custom date input that we can just completely throw away at that point and delegate to the browser.
- deergomoo 5y ago> every good browser but safari desktop (it's in technology preview) It’s finally in the mainline release now as of version 14.1!
- selimnairb 5y ago“ “Time Difference” (“Zeitverschiebung”) lists time zones for cities etc. – for example, the time zone for San Francisco is America/Los_Angeles.” Does anyone know how the canonical cities/regions associated with a time zone were determined? It seems kind of arbitrary. Wouldn’t “America/California” or “America/Sacramento, CA” make more sense?
- roywiggins 5y agoThere is also US/Pacific, which is just an alias for America/Los_Angeles. America/California is ambiguous, because there are several Californias in the "America" area, which encompasses North and South America. https://en.wikipedia.org/wiki/Tz_database#Location https://en.wikipedia.org/wiki/Tz_database#Location > Country names are not used in this scheme, primarily because they would not be robust, owing to frequent political and boundary changes. The names of large cities tend to be more permanent... > Usually the most populous city in a region is chosen to represent the entire time zone, although another city may be selected if it are more widely known, and another location, including a location other than a city, may be used if it results in a less ambiguous name. Basically: globally, regions and countries change, but cities are much slower to change. They don't just pick up and move like borders can.
- Groxx 5y agoAFAIK the common case is that it's just "whatever is in ICU/CLDR", there is no "standard". And I've seen them renamed many times - OS versions don't always agree with each other, for example, much less different OSes.
- deleted 5y ago[deleted]
- x1798DE 5y agoThe full theory on how the names are selected is here: https://www.ietf.org/timezones/tzdb-2021a/theory.html#naming https://www.ietf.org/timezones/tzdb-2021a/theory.html#naming For most zones, it's the largest city in a region where the timekeeping has been the same since 1970. This can cross state or national boundaries.
- brundolf 5y agoThe stable polyfill (and eventual native version) can't come soon enough. We're looking to move off of Moment given its deprecation status and how much it bloats our bundle, but we're waiting so we can go straight to Temporal instead of another intermediate library
- epaulson 5y agoI've been looking at the calendar and date types for BACnet, which is a protocol used in building automation (and hence, scheduling is super-important) - one of the things that it's got is some nice support for repeating dates/date patterns, sort of like cron but with odd extensions. (Because you might want to run a fan or purge a storage tank on specific days) For example, month is a number between 1 and 14, where 1 through 12 are Jan-Dec, but a month of '13' means "Odd Months" and month '14' means 'Even Months', and there's an explicit 'Not specified' for things you might want to run every month. Similarly there are special values for 'Even Days' and 'Odd Days', and special values for Week of Month: 1-7(1), 8-14(2), 15-21(3), 22-28(4), 29-31(5), 'Last 7 Days of the month'(6), and 'Unspecified'(255) I like that there's nice compact and standard ways to express and serialize these common choices. I wish there was something like that included in temporal but it doesn't look like there is?
- sedatk 5y agoIt's not even on caniuse.com or kangax.com's browser compatibility tables. I think it'll be a while before we can use this in production.
- brundolf 5y agoIt's in Stage 3. When it hits Stage 4 the API will be locked in and there should be a stable polyfill available. It may be a while before you can drop the polyfill, but it shouldn't be too long until you can use it
- Vinnl 5y agoExcept for this warning, unfortunately: > Although Temporal is currently Stage 3 in order to gather feedback from implementers, implementers must ship Temporal support behind a feature flag until we finish work with IETF to standardize the string formats used for calendar and time zone annotations https://github.com/tc39/proposal-temporal/issues/1450 https://github.com/tc39/proposal-temporal/issues/1450
- dheera 5y ago> Temporal does not support parsing human-readable strings. Well shit, that's one of the biggest things I want from a time library. There are about 15 different forms of human readable string formats that various APIs give you in their JSON responses and if they don't solve that, they haven't solved the biggest pain point. I guess congratulations for not solving the problem and instead making Javascript even more complicated to use by introducing yet another date library that skirts around perhaps the most important feature.
- dengsauve 5y agoI was equally disappointed to see this feature absent.
- 8bitsrule 5y agoMandatory XKCD. One last time? https://xkcd.com/927/ https://xkcd.com/927/
- lazarljubenovic 5y agoParsing human-readable strings is application-specific. It's good that this is kept in userland. Not matter how they do it, it's not going to work for at least 50% of use-cases. It would result in additional bloat of Temporal that's probably useless to you anyway. How do you parse (and do you parse) “01. 02. 2003.”, “jan 2 2003”, “2nd jan '03”, “today”, and “tomorrow night”? The API should parse only the ISO standard(s).
- andrew_ 5y agoDoes it strike anyone else how inelegant this new API is? With the plethora of accepted date/time packages out there with wide usage, this is the most cumbersome API surface of them all.
- tobyhinloopen 5y agoLooks like JS-Joda, I like it
- andyferris 5y agoIf we are going to nanosecond precision, I'm a little surprised Temporal doesn't include a `TAIInstant`? Maintaining a leap-second table (and the conversion logic) sucks for the same reason that maintaining your own copy of tzdata sucks. It really wouldn't need any methods other than a (possibly lossy) conversion to or from the corresponding UTC `Instant`.
- fanf2 5y agoWhere are you going to get TAI from without a leap second table?
- henryw374 5y agovarious replies mention java.time and the similarity Temporal has to it, so I'm posting a comparison I did a while back: https://widdindustries.com/ecma-temporal-vs-java-time/ https://widdindustries.com/ecma-temporal-vs-java-time/