Comment by LegionMammal978

I do find it annoying how the Temporal API, just like nearly all other datetime APIs, has 0 support for querying leap-second information in any shape or form. Suggested workarounds like temporal-tai all require plugging in a leap-second file and keeping it updated, which is especially painful for client-side JS, where you can't just download a leap-second file from someone else's site thanks to the SOP. Meanwhile, browsers update on a cadence more than sufficient to keep an up-to-date copy, but the datetime APIs refuse to expose leap-second info because they're too committed to "only UTC is in-scope for this project".

(The context is that I want to write some JS tools for astronomical calculations, but UTC conversions need leap-second info, so this trend makes it impossible to write something that Just Works™.)

schiffern 8 hours ago

  >only UTC is in-scope for this project

  >tools for astronomical calculations

Pity, since UTC is objectively the wrong time for astronomical calculations. Among other problems, UTC runs slightly slower or faster depending on how far the Earth is from the Sun. UTC does not run uniformly (outside of Earth-at-sealevel), instead the length of 1 second will slightly grow or shrink depending on the current configuration of the Solar system.

As you allude to, the correct time scale for this purpose would be TBD (aka Barycentric Dynamical Time), which applies relativistic corrections to act like the atomic clock is fixed at the barycentre of the Solar system. This is the only clock that actually runs "smoothly" for the purposes of astronomical calculations.

https://stjarnhimlen.se/comp/time.html

https://www2.mps.mpg.de/homes/fraenz/systems/systems2art/nod...

Reply View 4 replies

zokier 7 hours ago

> Among other problems, UTC runs slightly slower or faster depending on how far the Earth is from the Sun. UTC does not run uniformly (apart from Earth-at-sealevel), instead the length of 1 second will slightly grow or shrink depending on the current configuration of the Solar system.
That is completely wrong. UTC seconds are exactly SI seconds, which are all the same uniform length (defined by quorum of atomic clocks).

Reply View | 3 replies
- schiffern 6 hours ago
  
  At sea level on Earth, UTC seconds are all exactly the same, yes. That's the definition of UTC.
  The trick is, when you're working with things on the scale of the Solar system and larger, it no longer makes sense to assume your frame is "at sea level on Earth." Your relativistic reference frame has shifted, so (thanks Einstein!) time literally changes underneath your feet.
  The primary mechanism (but not the only one) is that a clock on Earth will tick slower when Earth is closer to the Sun, due to the effects of gravitational time dilation.[0]
  So yes, a clock on Earth always runs at a uniform rate. But because the universe is fundamentally Einsteinian, that still means that eg if you're working with the orbit of Jupiter or a millisecond pulsar, you will see small introduced timing errors if you try to use UTC (or even UT1 which is UTC without leap seconds) instead of TBD.
  [0] https://en.wikipedia.org/wiki/Gravitational_time_dilation
  
  Reply View | 2 replies
  
  zokier 4 hours ago
  
  But it's all relative, all reference frames are different and relative from each other and there is no one reference frame that is somehow special. TBD runs unevenly relative to UTC as much as UTC runs unevenly relative to TBD.
  
  Reply View | 1 reply
  
  schiffern 4 hours ago
  
  Absolutely, I completely agree. Einstein has taught you well. ;) The only thing that matters is choosing the right reference frame for the job.
  When high accuracy is required, UTC is not the right reference frame for the job of astronomical calculations. That's all.
  
  Reply View | 0 replies

nightpool 21 hours ago

> where you can't just download a leap-second file from someone else's site thanks to the SOP

WDYM by this? Why does the SOP prevent a website from hosting a leap seconds file? All they need to do is set Access-Control-Allow-Origin to allow websites to access it. Or provide it as a JS file—in which case no headers are necessary at all. All the SOP prevents is you hotlinking someone else's leap-seconds file and using their bandwidth without their opt-in.

> Meanwhile, browsers update on a cadence more than sufficient to keep an up-to-date copy

Is this true? I don't know any browser right now that ships with a copy of a leapseconds data file. Adding such a data file and keeping it up to date would probably be a pretty non-trivial task for new browser developers—just for something the browser will never end up using itself. It's not like the ICU/CLDR files where browsers are going to need them anyway for rendering their own user-interface components.

Reply View 2 replies

LegionMammal978 21 hours ago

> All they need to do is set Access-Control-Allow-Origin to allow websites to access it. All the SOP prevents is you hotlinking someone else's leap-seconds file and using their bandwidth without their opt-in.
They can, but the major providers (read: the ones I would trust to update it) don't. The IERS doesn't [0], the USNO doesn't [1], IANA doesn't [2], and NIST uses FTP [3]. Keep in mind that these files are constantly being downloaded by various clients for NTP and whatnot, it's not like these providers want to restrict public access, they just don't bother to set the header that would allow JS requests.
> Is this true? I don't know any browser right now that ships with a copy of a leapseconds data file.
From ECMA-262:
> It is required for time zone aware implementations (and recommended for all others) to use the time zone information of the IANA Time Zone Database https://www.iana.org/time-zones/.
Any browser that ships with a copy of tzdb, or knows where to find a copy from the OS, should have access to its leapseconds file. Unless you mean that all of them go solely through ICU and its data files? Which I suppose could be an obstacle unless ICU were to start exposing them.
[0] https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list
[1] https://maia.usno.navy.mil/ser7/tai-utc.dat
[2] https://data.iana.org/time-zones/tzdb/leap-seconds.list
[3] ftp://ftp.boulder.nist.gov/pub/time/leap-seconds.list

Reply View | 1 reply
- GeneralMaximus 11 hours ago
  
  Could you put some kind of CORS proxy in front of those URLs? (I know it sucks that you have to do this at all, but c'est la vie.)
  You could even write a Cloudflare Worker or a Val on val.town to do that, and add a bit of caching on top so you don't hit your providers too often.
  
  Reply View | 0 replies

burntsushi 20 hours ago

> but the datetime APIs refuse to expose leap-second info because they're too committed to "only UTC is in-scope for this project".

This doesn't make sense on at least two different levels.

First, pedantically, the definition of UTC as a time scale is that it includes leap seconds. So if you're committed to UTC, then you're supporting leap seconds.

Second, and to more broadly address your point, you should say, "they're too committed to 'only the POSIX time scale is in-scope for this project.'" That more accurately captures the status quo and also intimates the problem: aside from specialty applications, basically everything is built on POSIX time, which specifically ignores the existence of leap seconds.

Reply View 5 replies

LegionMammal978 20 hours ago

Sure, but my gripe isn't even that we ought to change the "POSIX time by default" status quo (the ship has long sailed that everyone counts durations by 'calendar seconds'), it's that the underlying libraries don't even provide enough information for "specialty applications" to reliably correct for it, short of perpetually updating it themselves.

Reply View | 4 replies
- burntsushi 20 hours ago
  
  Why should they though? To me it seems like a niche of a niche. I think there is plenty of room for scientific datetime libraries to service this need in a way that is likely better than what a general purpose datetime library would provide. (And indeed, there are many of them.)
  I say this as someone who had leap second support working in a pre-release version of Jiff[1] (including reading from leapsecond tzdb data) but ripped it out for reasons.[2]
  [1]: https://github.com/BurntSushi/jiff
  [2]: https://github.com/BurntSushi/jiff/issues/7
  
  Reply View | 3 replies
  
  LegionMammal978 19 hours ago
  
  > (including reading from leapsecond tzdb data)
  That's part of it: If I were writing a standalone program that could extract info from tzdb or whatever, I'd happily jump through those hoops, and not bother anyone else's libraries. I don't really care about the ergonomics. But for JS scripts in particular, there is no information available that is not provided by either the browser APIs or someone's server. And such servers are not in great supply.
  
  Reply View | 0 replies
  
  kortilla 11 hours ago
  
  It’s not “niche” if you do things synchronized to GPS timestamps. (i.e. a significant portion of telecom, a bunch of electrical grid stuff, etc).
  Anything using GPS as lock references to synchronize stuff that needs to be aligned to the millisecond absolutely cannot tolerate stuff like “the leap second smear”.
  
  Reply View | 1 reply
  
  burntsushi 37 minutes ago
  
  "niche" doesn't mean "unimportant." It just means "uncommon." It's a relative term.
  The vast vast majority of people using general purpose datetime libraries are not in need of GPS handling or high precision scientific calculations.
  
  Reply View | 0 replies

hgs3 13 hours ago

> like nearly all other datetime APIs, has 0 support for querying leap-second information

That's probably because you only need leap second accuracy in niche use cases, like astronomy or GPS. In JavaScript specifically, that kind of accuracy isn't needed for 99% of client-side use cases. Most date-time libraries work with POSIX time which assumes 86,400 seconds each day.

Reply View 0 replies

mr_toad 14 hours ago

Can’t you just mirror the data? You could even embed it in the javascript file itself.

Reply View 1 reply

[removed] 13 hours ago

[deleted]

Reply View | 0 replies

paulddraper 11 hours ago

> I do find it annoying how the Temporal API, just like nearly all other datetime APIs, has 0 support for querying leap-second information in any shape or form.

That’s because human time keeping doesn’t use leap seconds.

Reply View 0 replies