I know its not the answer, but I always convert time into time in seconds since the epoch and perform the arithmetic.
epoch time understands negative numbers:
% date -ur -28501440617 Mon Oct 29 05:09:43 UTC 1066 %
epoch time understands negative numbers:
% date -ur -28501440617 Mon Oct 29 05:09:43 UTC 1066 %
That is, "convert time into time in seconds since the epoch" is the hard part. All you've done is make it someone else's problem, while the question Skeet answered asked specifically about the time difference between 1927-12-31 23:54:08 and 1927-12-31 23:54:09 in Singapore.
The POSIX spec exists for this reason. This feels like a variation of "omg utf-8 is hard" which is why people embed utf handling in the language python2 -> python3
What does POSIX have to do with anything? Eg, the tz database isn't POSIX.
I'm sorry if I came across as churlish. Do you feel this is a problem of concept in abstract, or in java, or in java implementation or what? I feel it's a problem which I solve, by standing on the shoulders of smarter people and using the code they wrote. I don't reimplement the wheel because I distrust my own wheelmaking skills.
I'm sure there are heaps of non-trivial corner cases I don't have to deal with and I do not mean to minimise work done to explain a problem.
When it comes to timestamps, how do you handle midnight for example? 24:00 today represents the same instant as 00:00 tomorrow. The difference might matter to the user but disappears when converted to Unix timestamps.
Your response took things for granted.
dvt originally wrote "We stand on the shoulders of giants."
You commented "I feel it's a problem which I solve, by standing on the shoulders of smarter people and using the code they wrote."
It came across as totally missing dvt's point.
I picked Russian because I was thinking of an essay by Douglas Hofstadter. Quoting myself at https://news.ycombinator.com/item?id=16289783 :
> I think it was in Godel, Escher, Bach where he talks about the problem of translating a line from Russian, along the line of "He lived on B____ street." It's possible from the story, which takes place in a real city, to figure out which street that was. Let's say it was "Main Street". Does the English translation keep the original Russian word and initial? Does it translate to "Main Street" and replace the "B" with an "M"?
You can use a Russian-English translator to get a translation into English. But that doesn't help understand the hard problems involved, which was the point of Hofstadter's essay. (See, for example, his "The Shallowness of Google Translate" in The Atlantic; HN comments at https://news.ycombinator.com/item?id=16267363 and in dupes.)
You should still be careful how you define a _second_. A POSIX second is not the same as an SI second. A POSIX second corresponds to 1/(24 * 60 * 60) of a day. An SI second is defined using atomic time measurement. It means that the duration of a POSIX second depends on the length of the day, and some days are longer than others due to leap seconds.
The worst part is that most tools rely on POSIX timestamps instead of TAI timestamps (based on the SI definition). One of the consequences of using POSIX timestamps is that taking the difference between two timestamp does not safely return the number of elapsed seconds.
I don't think that is quite accurate. Traditionally Unix Time seconds are SI seconds, that tick in sync with UTC and atomic clocks (modulo clock error). To account for leap seconds, Unix Time has traditionally been discontinuous when a leap second occurs. Each second that ticks is still an SI second, but the sequence of Unix Time around a leap second will be X-2, X-1, X, X, X+1, X+2, etc.
This discontinuity means that every Unix Time day has exactly 86,400 seconds cumulatively, even though some days tick 86,401 elapsed SI seconds. So it is true that computing a difference between two Unix Time values does not give you a reliable measure of how many SI seconds have elapsed, as you say. But the individual seconds are still all SI seconds.
More recently it has become popular to smear the leap second instead. Google pioneered this approach in 2008 (https://googleblog.blogspot.com/2011/09/time-technology-and-...) and now advocates making it standard (https://developers.google.com/time/smear). This approach does vary the actual length of a second during the 24 hours surrounding a leap second. But this doesn't come from POSIX, it's a departure from previous practice that is designed to avoid a discontinuity.
> How any changes to the value of seconds since the Epoch are made to align to a desired relationship with the current actual time is implementation-defined. As represented in seconds since the Epoch, each and every day shall be accounted for by exactly 86400 seconds.
Another fact that I find interesting is that the use of discontinuities or time-smearing of the leap days are actually modern approaches. Nowadays, POSIX and TAI differ by an integer amount of seconds on regular days, and a fractional amount when smearing the leap-second day. At the beginning, the leap second duration between POSIX and TAI was smeared over years from one leap second to the other. So the difference between both timestamps would change continually other these periods!
My main takeaway is that POSIX timestamps are based on calendar days while TAI timestamps are based on physics constants. POSIX timestamps are a tradeoff: they're not suitable for time computations (durations, or even uniquely identifying an instant when discontinuities are involved) but they don't require a leap seconds lookup-table to display time for humans... in UTC... Which means you still need lookup tables for timezones, countries, DST, calendar changes, etc. Basically my opinion is that POSIX time is neither the best to precisely keep track of time nor to format it for humans. It just sits in between these two use cases because it was good enough at the time and then too hard to change.
[0]: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...
Do you have any reference to a system that was implemented this way? I have never heard of such a thing and I don't see how it could be implemented.
The insertion of leap seconds is unpredictable and occurs when the International Earth Rotation and Reference Systems Service determines that the difference between UTC and UT1 are approaching 0.9 seconds. Leap seconds are generally only decided six months or so before they occur. So you don't know at the beginning of the year how many leap seconds the year will have. So it doesn't seem possible to smear over a year.
> UTC is a discontinuous time scale. From its beginning in 1961 through December 1971 the adjustments were made regularly in fractional leap seconds so that UTC approximated UT2. Afterwards these adjustments were made only in whole seconds to approximate UT1. This was a compromise arrangement in order to enable a publicly broadcast time scale; the post-1971 more linear transformation of the BIH's atomic time meant that the time scale would be more stable and easier to synchronize internationally.
Wikipedia sources it to a book [1].
[0]: https://en.wikipedia.org/wiki/International_Atomic_Time#Rela...
[1]: McCarthy, Dennis D.; Seidelmann, Kenneth P. (2009). Time: From Earth Rotation to Atomic Physics. Weinheim: Wiley-VCH Verlag GmbH & Co. KGaA. ISBN 978-3-527-40780-4.
See: https://infiniteundo.com/post/25326999628/falsehoods-program...