4 ms·

Am I naive? It seems like POXIS ignoring leap seconds is a major mistake. Wouldn't a standard that means "number of seconds since January 1, 1970 UTC" be much m

• lxgr 2y ago
  > 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 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.
  • culi 2y ago
    If we simply stored all timestamps as "number of seconds since X" then we could safely convert that to whatever timezone, apply whatever leap adjustments, apply daylight savings time, convert to whatever calendar, etc anywhere we want 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.
    • lxgr 2y ago
      > If we simply stored all timestamps as "number of seconds since X" 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!
  • LegionMammal978 2y ago
    > 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 https://github.com/qntm/t-a-i instead. 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.
    • lxgr 2y ago
      > That solution, as with most simple leap-second solutions 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.