3 ms·
If utc is causing problems with your calculations due to leap seconds than you should be using Unix time to do the calculations and then translating that to a h
by throwawaytime99 4y ago
If utc is causing problems with your calculations due to leap seconds than you should be using Unix time to do the calculations and then translating that to a human readable format.
Imo society needs three distinct time counting systems.
1. Linux time. Essentially a universal addressing system for the measure of time in a agreed upon reference point (Earth’s surface). This should be the standard for science/computation, with the need for language to describe time dilation when comparing two reference points. Unix time doesn’t have leap seconds, or the concept of days.
2. UTC aka civil time. Things such as the orbit of the sun and the rotation of the earth aren’t in constant speed and don’t divide evenly with each other. UTC deals with short term variability with leap days and leap seconds. This is so every January 6th the earth is roughly in the same spot relative to the sun, and every 5pm the earth is in roughly the same part of its rotation. This is important because these things drift on human scale timelines. This calendar should be used for daily life, business, etc.
3. A purely astronomic calendar. A calendar that defines time by astronomic events. For example, defining a day as one rotation of Earth and not as a number of times an atom vibrates. This should be used so we can discuss astronomical events such as “A Martian year” or a “Saturn Day” and provide some meaning. This is the basics that should be taught to elementary school children to establish the cultural meaning of a day or a year and to provide some basic learnings of nature.
- BoppreH 4y agoUnix time does have leap seconds. From Wikipedia: It is the number of seconds that have elapsed since the Unix epoch, excluding leap seconds. Yes, it means the Unix timestamp jumps around, either skipping or repeating a second, when there's a leap second. Yes, it is as stupid as it sounds.
- cpcallen 4y agoI think this is the real problem. If we used a unix-time-including-leap-seconds instead then the date/time conversion functions would need to have a little extra smarts (a table of leap seconds in addition to a timezone database) but most of the leap second related problems would not exist. (We already deal just fine with months having variable numbers of days. Minutes having variable numbers of seconds is obviously awkwardly rare from a testing point of view, but not fundamentally more difficult to get correct.)
- dane-pgp 4y ago> not fundamentally more difficult to get correct The fundamental difference is that we can predict well in advance how many days will be in a given month, and the rules for calculating that number can be implemented with a short lookup table and a few modulo operations. The lookup table for past leap seconds, however, is already longer than 12 entries, and there is no way of calculating the length of all future minutes. On the other hand, the problem may be simpler than keeping track of changes to timezone definitions, since there are hundreds of jurisdictions that can unilaterally change those.
- deleted 4y ago[deleted]
- deleted 4y ago[deleted]