3 ms·

Are they truly? There must be a good reason but I can't fathom what it could be

• heartbeats 7y ago
  Because otherwise you would get annoying off-by-27 errors whenever you did time() % 60. https://en.wikipedia.org/wiki/Leap_second#Binary_representation_of_the_leap_second https://en.wikipedia.org/wiki/Leap_second#Binary_representat...
• GolDDranks 7y ago
  That good reason is that there is no general "formula" for leap seconds, unlike for leap years, they have to be looked up. So you can't do "offline" date calculations if they included leap seconds. I think that UNIX time stamps are generally a very good approximation, and if you are comparing long enough time intervals for the error to get over one second, and/or that error to matter, you are doing something wrong anyway. For exact time interval measurements that you have to get exactly right, don't use UNIX time stamps.
  • Misdicorl 7y ago
    The lookup database is incredibly small and updated very infrequently. Certainly smaller and less frequent than tzinfo which is also included in the kernel
    • labawi 7y ago
      AFAICT leap seconds are announced about 6 months in advance (January/June). How would you process times that are to occur after a leap second that may or may not be? You could store something as '2022-02-02 02:22:22 UTC', but try storing it as seconds since epoch, if you don't know if there will be leap seconds. Not to mention software that may be years or decades old.