JavaScript dates are about to be fixed
docs.timetime.in
docs.timetime.in
Rust's Chrono? Outstanding. You can find flaws, but it's generally predictable, and most importantly, has fewer flaws than those in other languages. Python's? Kind of messy, but usable. JS's Date and Moment? Unusable.
As somebody having both caused and fixed many time-related bugs in a financial/payments context, this sentiment is creating an almost physiological reaction at this point.
If your real-world process is concerned with things happening on particular days, don't represent these as midnight, i.e. 00:00, of that day. You'll thank me the day your company starts hosting servers or interacting with a customer/vendor in a different timezone.
Essentially, this is just a corollary of "don't imply more precision in your internal data representation than was present in your data source", but it bears repeating when it comes to date/time processing too.
(And please, please don't ask me about the difference between "Y" and "y" in Java's SimpleDateFormat, but look it up before you ever use it, thinking they're equivalent... Because on some days of some years, they are not.)
[1] https://docs.oracle.com/en/java/javase/17/docs/api/java.base...
The important information I was missing was "the week-based year and the year-of-era representations of one and the same date differ on some days, but not all days, and especially not those days you're currently using in your unit tests".
And even if it wouldn't – SimpleDateTime was the non-deprecated standard library method I found at the time that seemed to do my job, so that was the one I used.
I was wrecking my mind trying to come up with a scenario where what we did could go wrong with DST shifts alone (i.e. without a timezone conversion/relocation), but fortunately, most (all?) of Europe shifts DST on a weekend, never at the last day of the month, and with ample safety buffer from midnight, for which I am very thankful.
DST problems can manifest in a lot of interesting ways. That's why it's important to use a datetime library that does DST safe arithmetic (like Temporal).
Not doing the shift on a weekday or the last of the month alone has probably prevented countless bank batch jobs from exploding.
Sizable portion of society were late that Monday (most probably don't have repeating alarms on the weekend so I guess it went unnoticed for most).
Best part. After making headlines all around, apple managed to have the same/similar bug next year.
The amount of hell that ensued was never-ending. I'm not sure we ever truly fixed the issue, it's so hard.
There's still apps at my company that use the server's local time for everything, built in a pre-cloud world. Now we "cloud host" many of these, by running sets of VMs with their clocks set to different timezones and setting up each tenant on one matching their zone. Unfortunately, it's a product that makes a fair bit of money but isn't our focus (not much growth or new sales), so it's never been worth it to actually do something better.
It's not just the timezone/DST issues, either. Another product I've worked on did the "reports at midnight" thing, but as it grew it became impossible, as it took hours to complete all reports for all customers. So some "scheduled at midnight reports" would happen at 1:28am. This alone isn't a huge deal, but many reports were time-dependent (eg: you get different results running at 1:28 vs 0:00), and for a subset of those it was actually a big problem. So some got fixed by removing the time dependency (basically making the queries in the report have end times vs using now()). Another workaround was to staggering times manually on other reports - run at 2:30am - but still many customers would still pick 1:00 or 2:00 (which is of course someone elses' midnight), and there were still big I/O bursts on :00, :30, :15 and :45, especially overnight.
My personal takeaway was to avoid building report systems like that, and try to do things like let the user pick "Daily" without picking the time-of-day. For time-sensitive "reports" it's been my experience that if you actually dig into the user needs, they're really looking for an "operational view", not a report. It requires specific dev work to build of course, but the end result is better both technically and for the customer, and is less overall work than all the fixes/workarounds needed when you try to shoehorn it in with all the other reports, especially as the usage grows.
The choice of 'Y' for the rarely used "week year" is unfortunate. For those unaware, in ISO-8601 every year has either 52 or 53 full weeks. If you want to format a date like "2023-W52-6" (the 6th day of the 52nd week of 2024) you would use "YYYY-'W'ww-u".
https://unicode-org.github.io/icu/userguide/format_parse/dat...
Matrix's e2ee message formats have a form of this issue. The AES IVs generated are only a subset of the possible IV space than the cryptography actually uses. This gets expressed in the JSON base64 string storing the IV always having an AAAAA prefix for the zero-padding.
I'm not sure if this is still true and I don't believe it was responsible for any security vulnerability due to how the IVs are used, but it's still a sloppy design.
The new temporal api discussed in TFA includes more robust calendar support and more flexible zoned DateTime than Luxon afaict.
There has been no meaningful change in this proposal for some time now.
Perhaps in 6 months, hopefully I'll be proven wrong.
But there's no reason to suspect that now is the time.
One of the biggest problems with Javascript's Date is that there is no way to change the timezone context--you are stuck with whatever the system timezone is.
Presumably this new API will fix the fact that JS does in fact know about some time zones, but not most.
Shield your eyes from this monstrosity that will successfully parse some dates using `new Date(<string>)` in some select special time zones, but assume UTC in the other cases:
https://github.com/v8/v8/blob/781c20568240a1e59edcf0cb5d713a...
This bit me hard in a previous role. :'(
It knows about 8 time zones in 4 different offsets, and that's it?
I ask because yes, everything on the site points that way. But it's still so hard to believe that some confirmation would be good.
Unofficially schools tell students to use Chrome because some tasks fail often outside of Chrome. In particular Safari's default settings for cookies/privacy often causes the system to fail - particularly with integrations that use iframes/popups and other antiquated tricks.
The year is 2024.
I feel like we peaked somewhere around the mid 2010s with regards to application compatibility: No more Flash, but also more than just 1.5 rendering engines.
Before that, it was all "oh, sorry, Windows .exe only"; since then, "sorry, Chrome visitors only".
I don't think this is correct. I think the JavaScript spec here defines a string format which is extremely narrow, but then leaves it open to browsers implementing whatever they want.
https://262.ecma-international.org/5.1/#sec-15.9.4.2
> The function first attempts to parse the format of the String according to the rules called out in Date Time String Format (15.9.1.15). If the String does not conform to that format the function may fall back to any implementation-specific heuristics or implementation-specific date formats.
https://262.ecma-international.org/5.1/#sec-15.9.1.15
> ECMAScript defines a string interchange format for date-times based upon a simplification of the ISO 8601 Extended Format. The format is as follows: YYYY-MM-DDTHH:mm:ss.sssZ
> Z is the time zone offset specified as “Z” (for UTC) or either “+” or “-” followed by a time expression HH:mm
> Note2: There exists no international standard that specifies abbreviations for civil time zones like CET, EST, etc. and sometimes the same abbreviation is even used for two very different time zones. For this reason, ISO 8601 and this format specifies numeric representations of date and time.
The hint as to what is going on then comes from MDN, which more documents the ground truth than the goal.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
> There are many ways to format a date as a string. The JavaScript specification only specifies one format to be universally supported: the date time string format, a simplification of the ISO 8601 calendar date extended format. The format is as follows: YYYY-MM-DDTHH:mm:ss.sssZ
> Note: You are encouraged to make sure your input conforms to the date time string format above for maximum compatibility, because support for other formats is not guaranteed. However, there are some formats that are supported in all major implementations — like RFC 2822 format — in which case their usage can be acceptable. Always conduct cross-browser tests to ensure your code works in all target browsers. A library can help if many different formats are to be accommodated.
That table then comes from RFC2822, which also doesn't want you to use string named time zones, but as RFC822 has such it needs to still support it a bit--I imagine this probably came from back when this was used by ARPA-- and so has a section on "obsolete" date and time format extensions, which only explicitly requires support for US time zones and (notably) military formats.
https://datatracker.ietf.org/doc/html/rfc2822#section-4.3
"UT" / "GMT" / ; Universal Time
; North American UT
; offsets
"EST" / "EDT" / ; Eastern: - 5/ - 4
"CST" / "CDT" / ; Central: - 6/ - 5
"MST" / "MDT" / ; Mountain: - 7/ - 6
"PST" / "PDT" / ; Pacific: - 8/ - 7
%d65-73 / ; Military zones - "A"
%d75-90 / ; through "I" and "K"
%d97-105 / ; through "Z", both
%d107-122 ; upper and lower case
So, a spec, sure, but not the JavaScript spec, and not because if Chrome supported something weird then JS would get mad (as JS nigh unto suggests going above and beyond), and even RFC2822 (itself already outside JS) leaves open the door for more zones... in practice, I actually think JavaScriptCore might support even more formats (but could be totally wrong on that)?
Anyway, yeah, that does explain the situation we are in. And yeah, it looks like if you are extremely literal-minded and insist on supporting obsolete notations on your new thing, that would make your code be exactly like the one the OP pointed.
It's a bad decision all around, because the RFC 2822 isn't concerned about general purpose time handling. A programing language shouldn't use something like this.
Somebody posted the spec as a reply, and looks like the standard can be read in a way that mandates exactly that.
The author confuses the concept of injectivity and well-definedness. For an injective function f, it has to be true that given distinct a and b, f(a) != f(b). That's not the problem here; rather the problem is that for a timestamp t there's no unique human-readable date x such that f(t) = x. That's well-definedness, not injectivity.
https://en.wikipedia.org/wiki/Well-defined_expression
You could talk about the inverse function, from human-readable dates to timestamps, and correctly point out that that function is not injective, because more than one human-readable date maps to the same timestamp...
if t is 17943000... whatever
which translates to say
03:50 AM on Mar 16, 2020 in Greenwich (i.e. UTC+00.00)
then it can be converted to any other human readable zoned time.
Where is the issue?
For example, given just a timestamp, you don't even know what day it was. Was the user in New York? That 3:50am was actually 11:50pm on March 15th.
I would assume in 99% of cases the user is simply just interested in his local time anyway.
If you really need the location info, then you would obv have to make some other tradeoffs like either
1) always store the location alongside the timestamp or
2) complicate (probably massively so) the time format, storing and parsing/processing logic
But I don't see how that's an issue of UTC timestamps per se rather than being an issue of requiring more information than just time (i.e. time AND location at the time).
Again, really would appreciate an explanation of where I am mistaken here because thus far the whole point of OP seems like a trivial non-issue to me.
Let's say we schedule a meeting for next year at 15:00 local time in SF. You store that as an UTC timestamp of 2025-08-24 22:00 and America/Los_Angeles timezone. Now, imagine California decides to abolish daylight savings time and stay on UTC-8 next year. Our meeting time, agreed upon in local time, is now actually for 23:00 UTC.
Google Photos also get confused with "When was this picture taken?", my older model camera just stores the EXIF date in "local time" and I have to remember to change its timezone when travelling, and if GPhotos can't figure it out, it might show pictures out of the airplane window, and then the next series of pictures are from the departure airport because they're from a "later" hour (since it's missing the timezone info).
I suppose I could keep it at my home time or UTC...
The photos problem is harder, but the app needs to just convert it from local time to UTC when you import it. There's not much that can be done if you take photos on a camera with a different time zone than you're in without more metadata.
> That is how I would expect a bank statement to read though. I would find it infinitely more confusing if I bought something online in my bank showed the time of wherever the seller was located.
When using my banking app abroad (one that does show timestamps), I'm usually much more confused by their presence than by their absence.
> The photos problem is harder, but the app needs to just convert it from local time to UTC when you import it.
But I usually want to see the time in local hours and minutes for photos! Sunsets, new year's fireworks etc. happen according to local time, not UTC or my current timezone's offset.
Sometimes, the local time at the place the photo was taken can make more sense, but it's not a general rule.
I've seen some software work around that by combining the local date/time with an embedded GPS tag, if present, which does contain the time in UTC.
[0] https://en.wikipedia.org/wiki/Daylight_saving_time_by_countr...
These days I try to encode everything that is logically a date as yyyy-mm-dd. And if I need to do math with it, I often work with an offset julian date as an integer. But that only works if you stay on this side of September 1752:
% cal 09 1752
September 1752
Su Mo Tu We Th Fr Sa
1 2 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30Wouldn't using Julian days prevent the ordinary problems involved with doing calendar math across a renumbering of the dates?
That way, you can identify all of:
- Future timestamps you might want to re-process, e.g. for notification scheduling, because the future UTC conversion has changed between scheduling/updating the event and now.
- Equivalently, timestamps written by software/an OS running an outdated TZ database. You should talk to them; things are about to go wrong if the date is in the non-too-far future!
- Trivially and without conversion, the local time that people will use in the meeting notes, documenting that you missed the meeting because you didn't update your TZ database and dialed in to the meeting an hour late
Or what if it is specifically about time in timezone independent way? You want to wake up ate 06:00 no matter in any timezone. Just something like alert.
You could use part of ISO8601 like 2020-02-02 or 06:00:00 to store exactly what you specify. But with timestamp, not so much.
Often it feels like you can "just use UTC" because it's hard to imagine the fail states, and APIs often make tz assumptions for you so you may never notice those fail states (occasionally your software will just be buggy and annoy a user, decreasing the feeling of quality and trust - it may never result in a disaster).
Edit to add: still, this sounds like a great improvement. A common mistake that naive programmers make is to believe that they can hand-roll their own date/time functions. And JavaScript sort of forces them to do that.
See also Falsehoods programmers believe about time at https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b...
For example, if you are trying to say “run this task at this specific time in Los Angeles time” and you put a specific UTC offset, it just doesn’t make any sense. Los Angeles time consists of two offsets, and yet here you openly put down something wrong. You need to put into your system literally Los Angeles time (like America/Los_Angeles) because that’s what you want. You didn’t want an offset. Dear god why are you putting an offset then?
Or you want to define a specific date but then you put into your system a date with a time like 12/12/2024 00:00. Like you started off with “I want to define a specific date” and here you openly just put a time. You had to make up 00:00. Why are you just doing random things without thinking?
There are date/time libraries that can't get all of this right, but you'll come a lot closer using them than you will rolling your own.
Don't store raw timestamps. Don't store offsets. Use date/time data types.
I can tell you from bitter experience that if you have an event where a person has to arrive at a place at a time and you store that as UTC instead of wall clock, you will have a problem at some point
Maybe a better argument is, “when you’re setting a phone alarm, you don’t tell it a timezone.” Maybe the distinction is whether the timezone is established at write time or read time.
Which coincidentally and ironically makes phone alarms surprisingly difficult to implement in a way that does not break in the face of DST shifts, timezone changes etc., as Apple has learned the hard way a couple of times.
Past/future does matter, as generally speaking it's possible to accurately convert between local time and UTC for times in the past, but not in the future.
There's a few exceptions where governments have retroactively changed timezones or DST rules, but at that point you've lost anyway.
The future is defined by intent which is imprecise (will Oregon drop daylight savings time or not — who knows?). I don’t know how many seconds it is until my next birthday, but I know exactly how many have passed since I was born.
That poor Jedi master is going to miss the recurring workgroup meeting at least twice per year though, after either DST switch :)
Maybe I'm thinking of a group with less experience than you had in mind, but novices do not even know about UTC.
But yes I agree. There's no way any other standard could resist a standard adopted by the IETF and implemented by the language of the web
> Timestamps with Additional Information
Oh, cool, we're finally adopting TAI!
The answer to this is RFC 9557, which was recently published. Rust's Jiff library (of which I am the author) supports it. And I believe java.time supports it. Otherwise, yes, adoption will take time. But it's the right way forward I think.
Can someone explain to me what this means? ISO date strings should capture that exact information. Sure, there are caveats to storing dates/times, but I find the idea that JavaScript (or any language) needs built-in constructs for this purpose to be questionable.
Beyond that, both Temporal and Date solve what should be very simple problems in very complicated ways. I've yet to run into a circumstance where ISO strings don't suffice.
Either this, or every project starts with a 200kb date library import. In reality, I haven't met a single project that I don't need to deal with dates and timezone. And I almost always have a date.ts in my utils library because I don't want to import a giant date library either. But for real, developers shouldn't need to deal with this. These operations and constructs that every sites need should be build into the language itself.
It's interesting you say this but then go on to explain that you roll your own date library. Doesn't that discredit the idea that the alternative for every project must be a 200kb date library? I agree that most projects work with dates and time zones in some way, but that doesn't mean we'd have to use moment.js in the absence of the Date API. There's plenty of incompetent developers that would still do as such in the current year, but then this becomes a whole different argument.
And even yourself don't use it. The library authors will. There will be someday that people take the existence of temporal date api for granted. And you have no choice but import the polyfill if you want to deal with old browsers.
Florida (and the USA as a whole) have been discussing getting rid of the daylight savings change on-and-off for several years.
If that law goes through in December of this year, the date I stored for my event will now be off by an hour because come July 2025 Florida will be on UTC offset -6, not -5.
On the other hand, if I store the date with a fully qualified tz database timezone like this: "2025-07-04 03:00:00 America/New_York" the time will continue to be displayed correctly because the tz database will be updated with the new offset information.
(Of course a tz identifier will be better than an integer offset, but I'm only half joking: https://en.wikipedia.org/wiki/Time_in_Indiana#tz_database)
But an actual lat/long pair is often neither available, nor desirable to be stored for various reasons.
Now that you mention it, I think I've seen some web applications that had a list of cities much longer than what's present in the TZ database for calendar scheduling purposes, probably to accomodate for just that future edge case.
The example really threw me; in the case where you assume that Florida stops observing DST, Florida is definitely not going to be part of America/New_York, so that example is guaranteed to have the same problem as the UTC timestamp.
If timezone offsets are separately stored (or the UTC normalized ISO strings), this still isn't sufficient to know which locale the offset is referring to since multiple locales use the same timezone offsets.
It gets even more complicated when different locales shift their timezone offsets throughout the year due to daylight savings.
It's hard, but it's not that hard so long as all the data is there. The biggest difficulty is working out the right frame of reference to store timestamps with. That's mostly only a catastrophic problem for future events involving people, but (as others in the thread note) it's still potentially an issue for audit (and other) data too.
Knowing which time zone a meeting is supposed to be held in is especially important around time zone changes.
Why not?
1. Leap seconds. They exist at irregularly spaced intervals based on the Earth's actual rotation, which is a) not perfectly consistent and b) ever so slightly, continuously, on average, slowing down. The offset would only allow you to figure this out, in principle, if you already had the UTC time - which has to be calculated from the timestamp in a complex way that accounts for leap second information retrieved from a database.
2. Time zones change over time. Some parts of the world use daylight savings time and others don't. It's possible in principle for a daylight savings time transition (which occurs on different dates in different parts of the world) to occur between two displays of the date, invalidating the offset.
3. Time zones change over (longer periods of) time. They've historically been created, removed or had their borders changed. Sir Sandford Fleming's system is now 148 years old (and there were others before it), and geopolitics happens.
4. Calendars. Maybe you don't care about, say, the eras of the Japanese calendar (https://en.wikipedia.org/wiki/Japanese_era_name), but some applications will require knowing about it. If you need to deal with history, then the conversion between Gregorian and Julian calendars will also depend on locale, because the Gregorian calendar was adopted at different points in different parts of the world.
tl;dr: dates are hard because they represent an intersection between adjusting a model to meet physical reality, with l10n/i18n concerns (even if you don't care about language translation). Both of those are hard enough individually already.
"Thank you for meeting with me on 2024-03-27T15:00:00-07:00! See you same time next week."
When was the next meeting?
https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a...
> If implementations revise time zone information during the lifetime of an agent, then which identifiers are supported, the primary time zone identifier associated with any identifier, and the UTC offsets and transitions associated with any Zone, must be consistent with results previously observed by that agent.
Basically, the timezone data must not change while a browser tab, a Node program, or a service worker is running.
AFAIK, this does not prevent possible timezone data mismatch between different versions of browser and server, or even different browsers on the same machine.
https://tc39.es/proposal-temporal/#sec-use-of-iana-time-zone...
Having worked with dates and times in both Java and JavaScript, I'm very happy with what I see in the temporal API. Huge improvement.
For timestamps (i.e. recording things that happened), I still believe all you need is UTC and a location.
The bank example is just a matter of poor UX, not lost information (surely the bank could map transactions to a local time zone if they wanted).
Note that there's also a Rust datetime crate, jiff, that's inspired by the Temporal API and features zone-aware datetimes (from burntsushi, author of ripgrep and Rust's regex library): https://crates.io/crates/jiff
I can't wait for it to be fully taken advantage of by things such as mui's date time picker. Imagine if after selecting the fall back day, it saw the transition and let you pick a time during the extra hour. If after selecting the spring forward day, it wouldn't let you pick a time during the hour that doesn't exist. Today that doesn't work because everyone uses different crappy third-party libraries and mui functions on top of a lowest-common adapter that certainly doesn't do stuff like "show me the DST transitions in this day".
This stuff matters sometimes; a user of my NVR wanted to save a clip during the fall back hour and got the wrong result because these things just don't work right today. https://github.com/scottlamb/moonfire-nvr/issues/244
What I’d like to have (in addition, not as a replacement) is timeless dates. I can store/carry a timezone manually, but give me a proper date[-notime] datatype. I mean, I sort of have it with just “yyyy-mm-dd” and calculating with temporary “T00:00:00Z” suffix. But why would this new format solve my “no timety” impedance mismatch?
More specifically, please give me all the components separately and then design interfaces which may accept any number of these and make sure it makes best sense. Dates without times, times without dates, dates or times with or without timezones, dates without months and/or days, days without years and/or months, weekdays, simply timezones, and so on. Having new dates like subj is yet another piece in the date logic tetris you have to play. Stop imagining developer stories and make them all 1x1 square.
What is a good primer in understanding most of the serious issues raised in this thread and how they manifest themselves in (preferably) languages like Python?
https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a...
Just use a timestamp — if you need to know the associated timezone, just store that as well. Done.
But most often (when the timezone where the event was captured isn't relevant to the user or the business logic) conversion to local time is a frontend/view concern.
Safari’s saved credit card support works pretty well, but when I switch between US and Asia timezones the expiration date will shift by a month in one direction. My best guess is that they store the expiration as midnight local time on the 1st of the month in a js Date which can shift when you travel outside of that timezone.
Sure, Date could be better. I wish Dates were immutable. I wish UTC was the “default” instead of having to call all the UTC methods. And sure, formatting via toLocaleString() isn’t the most intuitive way to do things. But… it works and it’s pretty straightforward.
If I need time only without the date, there’s a method for that. If I want ISO 8601, there’s a method for that and it’s even the default when the Date is sent in JSON. If I want a UNIX timestamp, there’s a method for that and it’s even the default when the Date is used as a number, which also makes Dates easily comparable and sortable. The `Intl` API has a lot of ways to format Dates.
IMO Dates are underrated. Though they could benefit from a more ergonomic formatting method, a la `moment, maybe a more flexible parser, and some support for leap seconds.
So the new API will be a very welcome addition to the JS standard library.
However, and this is probably a bit off-topic, why are the ECMAScript guys not also addressing the fundamental reasons why JS continues to be somewhat a joke of a language?
- Where are decimals, to avoid things like `parseInt(0.00000051) === 5`?
- Why are inbuilt globals allowed to be modified? The other day a 3rd-party lib I was using modified the global String class, and hence when I attempted to extend it with some new methods, it clashed with that modification, and it took me and hour or two to figure out (in TS, no less).
- Why can't we have basic types? Error/null handling are still haphazard things. Shouldn't Result and Maybe types be a good start towards addressing those?
Because that was the original behavior, and you can't just change that behaviour, or half of the web will break (including that 3rd party lib and every web site depending on it)
> Why can't we have basic types? ... Shouldn't Result and Maybe types
Neither Result nor Error are basic types. They are complex types with specific semantics that the entire language needs to be aware of.
"use awesomeness"; from future import awesomnessBeing wedded to mistakes made in the past for fear of breaking current usage is the root of all programming language evil.
How do you imagine doing that?
> Being wedded to mistakes made in the past for fear of breaking current usage is the root of all programming language evil.
Ah yes, let's break large swaths of the web because progress or something
Like, you are asking for a Result type. If this was added to the spec tomorrow and existing objects were updated with new methods that return Result, and you can't modify built-in types, then you can't actually use the shiny new feature for years.
On the specific point of Maybe type, I think it's not very useful for a dynamically typed language like JS to have "maybe". If there's no compiler to check method calls, it's just as broken to accidentally call `someVar.doThingy()` when `someVar` is null (classic null pointer error) versus call `someVar.doThingy()` when someVar is Some<Stuff> or None, in either case it's "method doThingy does not exist on type Some<...>" or "method doThingy does not exist on type None".
And that's a good thing, because you know that with a specific version of JS, the inbuilts are fixed; no mucking around to know what exactly you have, and no global conflicts. I find it surprising that you would defend this insane state of affairs. If you have worked on really large JS projects, you would see my point immediately.
It is like saying the immutability of functional programming is a bad thing because it limits you. The immutability is the point. it protects you from entire classes or errors and confusion.
> If all the built-in types were locked down, we'd end up using those built-in types less because we'd more frequently need to use userspace libraries for the same things.
This is the correct solution for now.
There is a draft proposal for this: https://github.com/tc39/proposal-decimal
Additionally, BigInt has been available for years: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... (unfortunately does not serve as a u64 / i64 replacement due to performance implications and lack of wrapping/overflow behavior)
> - Why are inbuilt globals allowed to be modified?
> Error/null handling are still haphazard things.
How would you suggest addressing these in a way that is backwards compatible with all existing web content?
Version numbers. Solving the problem in the future but not the past is still better than leaving it unsolved in the future and the past.
The same reason you couldn't in 1996: because the assumed entry point for the language is someone who can barely conceptually manage HTML; doesn't want to have to deal mentally with the fact that numbers and text are fundamentally different kinds of thing; and - most importantly - absolutely will not accept the page failing to render correctly, or the user being shown an error message from the browser, for any reason that the browser could even vaguely plausibly patch around (just like how the browser has to guess whether an unescaped random stray < is just an unescaped less-than symbol or the start of an unclosed tag, or guess where the ends of unclosed tags should be, or do something sensible about constructs like <foo><bar></foo></bar>, or....)
I personally dislike decimals, I would prefer a full BigRational that is stored as a ratio of two BigInts (or as a continued fraction with BigInts coefficients.
Decimals solve the 0.1+0.1+0.1!=0.3 error but are still broken under division.
I’m looking for a particular build or deployment near a certain date and time and I must first calculate how many days ago it was then binary search through the items from that day.
Why would it mean that? It seems tangentially related at best. The sites you’re complaining about don’t use the presentation you’re complaining about for lack of more precise Date APIs, they use it intentionally as a feature (even if you consider it a misfeature).
And won't be available in non-chromium browsers and LTS versions of Node until 2028.
However, on one codebase I worked on in the past, dates were stored in mysql in a datetime field, with the time set to 00:00:00, iirc.
I’m hoping someone knowledgeable about this topic could comment on this. I never could discover why it was done that way. It wrong? Is it right? Based on the other threads here, it seems wrong, but maybe there’s a non-obvious reason to do it this way?
But does it mean that we need to add the space component to a timestamp ? Feels like 2 distinct things. Sure, when I record an event, I might not only want to record "when" it happened, and "where". But the "where" does not change or impact the "when", and vice-versa. Those feel 2 distinct properties to me, and I might want to store them separately.
Maybe I am missing something.
We need to record that whenever we want to talk to people about time and schedule things for them, just like we need to record their language and regional format preferences.
In other words, you might not need that level of metadata for a physical simulation, but you'll definitely need it for a calendar app. For everything in between, it depends, and the safest bet is accordingly to just do it, if you can.
Example: you want to schedule events in Madrid, Spain and Warsaw, Poland. Currently they both use the CE(S)T timezone, but the EU is looking into abolishing summer time - which would lead to countries adopting their own timezones. At the moment "Europe/Madrid" and "Europe/Warsaw" are identical to CET/CEST, but that hasn't always been the case in the past and obviously there's no guarantee it'll always be the case in the future.
If you stored those events as CE(S)T, what are you going to do when summer time gets abolished and Madrid ends up at +1:00 year-round but Warsaw at +3:00 year-round?
- https://github.com/js-temporal/proposal-temporal-v2/issues/5...
Does this mean that converting two DateTimes into their POSIX time and subtracting them will not yield an accurate representation of number of seconds between two timestamps?
It will indeed not, and if you care about that difference, you should not do that, and use something like https://github.com/qntm/t-a-i instead.
> Am I naive? It seems like POXIS ignoring leap seconds is a major mistake.
Depending on your needs it can be either seen as a massive mistake or a big convenience win.
In either case it's arguably not a complaint with POSIX, but rather with the commercial and scientific world at large using UTC instead of TAI (and there are indeed people arguing for abolishing leap seconds!). POSIX in turn just followed that standard.
Instead of browsers/libraries handling all the complexity (standards and localization, dst, leap seconds, etc), couldn't we just do all our math and logic in this format and then convert back to whatever when we need to display a time to a user.
It seems like saving a #seconds along with lat/long information is enough to handle all timestamp use-cases.
That works – if you never want to represent dates in the future (because we don't know how many leap seconds there will be in the future). But that way, you'd be incapable of implementing even a trivial calendar application involving more than one timezone.
> couldn't we just do all our math and logic in this format and then convert back to whatever when we need to display a time to a user
We could – using all the libraries encapsulating that complexity.
> It seems like saving a #seconds along with lat/long information is enough to handle all timestamp use-cases.
That's even worse, since often that's not available, and even if it is, now you need a database representing local UTC offsets as polygons on the surface of the earth!
That solution, as with most simple leap-second solutions, relies on the fixed file being kept up-to-date ad infinitum to account for any future leap seconds. Unfortunately, there isn't and still won't be any way to get a current list of leap seconds from JS, except for downloading them from someone else's API.
I never claimed it was a simple solution, just that it was necessary if you do care about that difference :)
The only solution that works for the future as well as for the past would be to schedule and communicate only in TAI, but good luck trying to convince the rest of the (non-scientific, and a good chunk of the scientific as well) world of that.
“5 days ago.”
“3 hours and 33 minutes.”
I’ve found this kind of thing to be the main reason I have to drag MomentJS along for the ride.
Likewise. It feels long overdue to have template based formatting natively.
I’m confident ChatGPT or Claude will write you one with one-shot prompt that does exactly what you want. Here’s an attempt at that: https://chatgpt.com/share/9bfe1d60-34cc-46fc-8327-3474c4a7d6...
Anything for maybe the last hour or I can see; "1 day and 5 hours ago" and making me hover over the string (and pray that there's an alt text available that I still can't copy-paste) is very annoying.
I really wish, space permitting, web designers would start at least including the actual timestamp in the regular/non-alt text as well, at the very least for professional tools if not for social media sites.
One time it works is when your team is across many time zones, the data being listed spans many time zones, and what’s important is knowing the recent events from older ones. And yes, also showing the absolute UTC stamps too
(Generally. I know plenty of shops deployed Exchange in 2009 and it still works so why fix it, goshdarnit! Those people aren’t generally updating their OS either though.)
The zone database adds more historic entries than they do modern ones. You can; however, calculate the correct 1942 "summer war time" in the british isles if you're so inclined. The tendency to do this while also copying copyrighted text into the file shows that the zone maintainers are not interested in the same problems most users are.
The TZ database is a complete mess. The whole thing should be replaced with a '.timezone' TLD, each civil time keeping authority should get control over it, and TXT records used to publish current TZ information. OS Vendors can cache all that in the OS if they like, but this secondary central time authority has outlived it's usefulness.
E.g., in the US, DST ends on Nov. 3, 2024 and the hour from 1:00 to 2:00 am will be repeated. Is there a way to distinguish the second pass from the first one?
A language-agnostic test suite should be provided, including every edge case, so that this standard can be implemented everywhere.
Who would have thought that a JS / TS backend framework would not only be a convenient but sane choice.
The challenge is that local computer time comes from a time and time zone set locally and stored in the hardware CMOS. That is not precise, varies from computer to computer, and provides all the offset problems mentioned in the article. Network hardware solved for that long ago using NTP. So the military applied a similar solution as an OS image enhancement that receives updates from a network time service whose time is defined according to the mesh of atomic clocks. Then it does not matter what offset is shown to the user by the OS when all your reports and data artifacts log against a universally synchronized time zone defined by a service.
The military solution works fine for the military but it requires centralized governance normal people do not have.
From the July TC39 meeting [0]:
> After 7 years, Temporal is close to done. Our only focus is making sure in-progress implementations are successful, by fixing corner-case bugs found by implementors, and making editorial changes to improve clarity and simplicity.
It's not (yet) on the October TC39 agenda [1].
The Chromium implementation issue hasn't been updated since 2022. [2]
Webkit's implementation issue was updated once this year... to add a blocker [3]
V8 is passing 75% of test262's tests, and JavascriptCore is passing 41%. Spidermonkey is a no-show. [4] Note that test262 is incomplete and hasn't seen activity this year [5], so those percentages may decrease over time.
"about to be fixed" ehhhh. If it lands this year I'd be surprised.
[0] https://ptomato.name/talks/tc39-2024-07/#2
[1] https://github.com/tc39/agendas/blob/main/2024/10.md
[2] https://chromestatus.com/feature/5668291307634688
[3] https://bugs.webkit.org/show_activity.cgi?id=223166
[4] https://test262.fyi/#|v8,v8_exp,jsc,jsc_exp,sm,sm_exp
[5] https://github.com/tc39/test262/issues/3002The polyfill is too heavy and the services we deal with seem to cover the whole range of dates and times. Julian, epoch, ISO-8601.
String.prototype.toTime = function () {
var time = this;
var post_meridiem = false;
var ante_meridiem = false;
var hours = 0;
var minutes = 0;
if( time != null ) {
post_meridiem = time.match( /p/i ) !== null;
ante_meridiem = time.match( /a/i ) !== null;
// Preserve 2400h time by changing leading zeros to 24.
time = time.replace( /^00/, '24' );
// Strip the string down to digits and convert to a number.
time = parseInt( time.replace( /\D/g, '' ) );
}
else {
time = 0;
}
if( time > 0 && time < 24 ) {
// 1 through 23 become hours, no minutes.
hours = time;
}
else if( time >= 100 && time <= 2359 ) {
// 100 through 2359 become hours and two-digit minutes.
hours = ~~(time / 100);
minutes = time % 100;
}
else if( time >= 2400 ) {
// After 2400, it's midnight again.
minutes = (time % 100);
post_meridiem = false;
}
if( hours == 12 && ante_meridiem === false ) {
post_meridiem = true;
}
if( hours > 12 ) {
post_meridiem = true;
hours -= 12;
}
if( minutes > 59 ) {
minutes = 59;
}
var result =
(""+hours).padStart( 2, "0" ) + ":" + (""+minutes).padStart( 2, "0" ) +
(post_meridiem ? "PM" : "AM");
return result;
};
https://stackoverflow.com/a/49185071/59087
One of my minor bug bears is why we humans have to enter time into input fields in such rigid formats when there's a straightforward algorithm to make such inputs far more natural.
It'll also convert "0:45" into "00:00AM" (and "0:23" into "11:00PM").
No, I wouldn't. Leaving out the leading zero is pretty common where I'm from.
So noon is "12 in the morning", which is an hour after "11 in the morning"; and midnight is "12 in the evening", which is an hour after "11 in the evening".
† That is, you follow 11:00 PM with 12:00 AM, and you don't actually refer to "AM" or "PM". Both of those are normal US practice. You are different in the use of 24-hour formats in writing, but that has no bearing on the question of whether the hour following 11 PM is 12 AM; you just assured me that that's true in both countries.
// Preserve 2400h time by changing leading zeros to 24.
time = time.replace( /^0*[0:]/, '24' );That converts "0800" into "00:00AM".
time = time.replace( /^0*(0:)+/, '24' );GNU date supports very human-oriented date input, some examples:
$ date --date "today"
$ date --date "next sunday"
$ date --date "now + 3 hours"
$ date --date "3 months" # same as "now + 3 months"
$ date --date "5 december 2020"
$ date --date "oct 19 2007"
$ date --date "08:00"
$ date --date "8:00"
$ date --date "0800"
$ date --date "0800 UTC"In any case, it’s about how the word is normally used. In normal language you never say something like “those two instants are three hours apart”, or “three hours passed between the two instants”. In contrast, you would say something like that with “points in time”. For example. one can say “this was observed at two different points in time”. Nobody would say “this was observed at two different instants”.
“This precision means that regardless of DST changes or any other local time adjustments, your date will always reflect the correct moment in time.”
Probably a failing on my part but I had somehow assumed all this time that calculating DST was a separate concern from time zone offset, given how tremendously opaque it can be.
To my knowledge, there is an area in Arizona that does observe DST, within an area that does not observe DST, within an area that does, within Arizona at large, which does not. Does this API really accurately represent this peculiar arrangement?
It looks like canonically there’s an America/Shiprock timezone but you’d think you’d need at least 4 to accurately represent the various areas.
https://upload.wikimedia.org/wikipedia/commons/3/38/AZNMUT_D...
What are you envisioning? That sounds like two timezones, with different regions belonging to one or the other. Does it matter to the API if two regions that aren't contiguous with each other share a timezone?
Currently the "Number" type is used for every number and it gets stored as a double, and can "only" represent "integers" safely in the range of ±(2^53 -1). Though there is a "BigInt" [1] type.
[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Data...
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Data...
* Integer types of various sizes (for efficiency) and so you don't have to constantly do floating point comparisons (i.e. equal within a small delta) and generally have better compatibility with other languages. * Decimal floating point type so you can work in base-10 and don't have rounding issues.
Plus all of the error checking you get for free if you're using typescript instead of raw-dogging it with plain javascript or coffee-script :-)
Everything just worked. Not one bug. A good library is so so helpful for complex use cases like dates.
Well, about time.
Wake me up when a browser ships Temporal.
Edit: Here’s Temporal on caniuse.com: https://caniuse.com/?search=temporal
Handful of APIs in the Safari Technology Preview, otherwise nada. I look forward to Temporal landing but it is still a very long way off.
So JavaScript gets what Java got in version 8, 10 years ago?
I would love to not have to import dayjs or another userspace library, so that i can pass datetime-with-timezone to other libraries and instead use an IETF standard way of handling time that's backed by performant native runtime code.
In my experience, userspace timestring parsing and timezone conversion can also be a surprising CPU bottleneck. At Notion, we got a 15% speedup on datetime queries by patching various inefficiencies in the library we selected. The runtime can be more efficient as well as saving page weight on tzdata and locale stuff.
"Let's consider an example: suppose I want to record the moment I make a payment with my card. Many people might be tempted to do something like this:
const paymentDate = new Date('2024-07-20T10:30:00');".
What? I don't think anybody would define a date like this to record some moment. Most developers would simply use new Date() without any parameters, thereby creating a timezone-safe absolute underlying timestamp value. This value then is of course stringified relative to the timezone of the caller when retrieving it, but that's expected.
The new Temporal api might be nice but it doesn't need flawed examples to make its case.
Their datetime formatting implementation is simply nuts. Why not follow standards? Why the NIH?
What? UNIX epoch? Central European Summer Time?