6 ms·

This post reminds me of one of Jon Skeet's seminal SO answers[1] on subtracting dates. Things we take for granted are hard. Dates are hard, text is hard, graphi

by dvt 7y ago

This post reminds me of one of Jon Skeet's seminal SO answers[1] on subtracting dates. Things we take for granted are hard. Dates are hard, text is hard, graphics are even harder. We stand on the shoulders of giants. It's important to stop and smell the roses every now and then. [1] https://stackoverflow.com/questions/6841333/why-is-subtracting-these-two-times-in-1927-giving-a-strange-result https://stackoverflow.com/questions/6841333/why-is-subtracti...

AmericanChopper 7y ago
I remember trying to debug this exact “issue” in a java project years ago. I poked around the library to figure out what was going on, which only raised more questions, before I eventually stumbled upon that exact SO thread. Turns out dates have an enormous amount of complexity.
- Joeri 7y ago
  Date and time are complex because they are social and historical constructs. Everything about them is arbitrary and exists because of arcane historical reasons. No regular system of organizing time maps cleanly onto the movement of heavenly bodies because those movements are not regular (hence: leap seconds). You can describe time in a way that is precise, or in a way that is intuitive, but not both, and woe to anyone trying to convert between the representations. Time zones are the worst because they are political tools, changed for political reasons, often with very little lead time. I think of them as a one way function mapping universal time onto the local political reality.
ggm 7y ago
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 %
- eesmith 7y ago
  It's easy for me to write something in Russian, I just hire a Russian translator for me. 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.
  - ggm 7y ago
    Yes. This is beautifully expressed. And 'hiring a russian interpreter' is almost always the right way to fix this kind of problem. POSIX would seem to me to be the russian interpreter of choice here. Is java a language which has no word for the colour green? in the sense where the eponymous russian interpreter has to say: "concept which cannot adequately be expressed in russian" or something 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
    - eesmith 7y ago
      It seems less than graceful to respond to articles which point out the existence and difficulty of problems by saying it's fixed. The entire point is to show how it's more difficult than many think, not elide the issues. What does POSIX have to do with anything? Eg, the tz database isn't POSIX.
      - ggm 7y ago
        The POSIX spec of date time specified conversions into a neutral form. Maybe it's C centric thinking but it felt like a problem which has existed and been solved by writing a 'russian interpreter' solution: convert the values on the edge to a canonical form and use functions which manipulate the canonical form. The TZ files i only mention because within the limit of modern epoch Times and dates they do a pretty good job of handling the minutia of what a local time means in any given period. 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.
- bouke 7y ago
  That’s not taking time zones into consideration, so might be off by an arbitrary amount of hours/minutes.
  - ggm 7y ago
    Obviously you would set TZ before up-converting. I spoke in UTC about an input time I specified in UTC. POSIX date time models understand timezones and on well configured systems understand prior states of time zone behaviours at boundaries like summertime into historical past states. The 1990s USENET discussions did at one point veer off into rotational speed of the earth MYA ago, I'm not sure many people cared but astronomers maybe have to. (I don't think dinosoars used summertime)
    - bouke 7y ago
      Historically correct timezone handling is one thing, but you also have to consider future timezone changes unknown at this time. For example some EU countries might decide to cancel daylight savings. Now your conversion from UTC is off by an hour.
- quickthrower2 7y ago
  One does not simply ... convert time
- coldtea 7y ago
  That has its own tons of cans of worms... See: https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time https://infiniteundo.com/post/25326999628/falsehoods-program...
- demurgos 7y ago
  > I always convert time into time in seconds since the epoch 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.
  - haberman 7y ago
    > A POSIX second corresponds to 1/(24 * 60 * 60) of a day. An SI second is defined using atomic time measurement. 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-leaping-seconds.html https://googleblog.blogspot.com/2011/09/time-technology-and-...) and now advocates making it standard (https://developers.google.com/time/smear 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.
    - demurgos 7y ago
      Yes, I definitely agree that the reality is even more complicated and there are different implementations. The recent time-smearing approach is closer to the POSIX standard [0]: > 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_chap04.html#tag_04_16 https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...
gambler 7y ago
> Things we take for granted are hard. Dates are hard, text is hard, graphics are even harder. We stand on the shoulders of giants. More like we stand on piles of broken shit. A lot of "hard" things in programming have very little fundamental complexity. They are hard because at some point in time someone made a compromise that no longer is relevant or makes any sense. It is possible to redesign those things to be simple, but modern developers are conditioned to fight this at every step. The idea that the first thing you should try to do when faced with extraordinary complexity is to bypass it is completely alien to people whose daily jobs consist of continuously banging their heads against convoluted frameworks and deficient APIs. Time handling is a great example. Until you get into general relativity, time itself is extremely simple and uniform. But human representations of time are extremely convoluted, because historically they are based on astronomy. Here is the kicker: 99.99% of all software has nothing to do with astronomy, and yet people chose to inject those complexities in core structures that track time. (For example, Unix timestamps have leap seconds, which is a source of innumerable bugs and ridiculous convolutions in code to prevent those bugs.)
- stnmtn 7y ago
  Are you arguing for trying to create a new method of tracking time instead of just including moment.js?
  - hrktb 7y ago
    I read parent’s comment as a plea to be simple where it’s allowed. For instance use straight timestamps where there is no need for calendar manipulations. I am sympathic to this argument and I’d also totally join a movement to ignore DST or uncouple years from earth rotation
  - m45t3r 7y ago
    This post sounds kinda like a satire: "we have problem X, did you try something.js to fix it?"
- rovolo 7y ago
  If by 'based on astronomy' you mean 'based on the sun' because the sun is a star, then I agree. But, plenty of software has lots to do with the sun because they have to interact with people, and people like to be synchronized with the sun. If you don't want software to interact with humans, or you only care about duration rather than human datetime, then go ahead and use UT1. However, as long as your interacting with people, you're going to need to fix people first. You should start with these primers if you're going to fix how humans interact with time: - https://qntm.org/abolish https://qntm.org/abolish - https://qntm.org/continuous https://qntm.org/continuous

by dvt 7y ago

AmericanChopper 7y ago

I remember trying to debug this exact “issue” in a java project years ago. I poked around the library to figure out what was going on, which only raised more questions, before I eventually stumbled upon that exact SO thread. Turns out dates have an enormous amount of complexity.

Joeri 7y ago
Date and time are complex because they are social and historical constructs. Everything about them is arbitrary and exists because of arcane historical reasons. No regular system of organizing time maps cleanly onto the movement of heavenly bodies because those movements are not regular (hence: leap seconds). You can describe time in a way that is precise, or in a way that is intuitive, but not both, and woe to anyone trying to convert between the representations. Time zones are the worst because they are political tools, changed for political reasons, often with very little lead time. I think of them as a one way function mapping universal time onto the local political reality.

ggm 7y ago

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 %

eesmith 7y ago
It's easy for me to write something in Russian, I just hire a Russian translator for me. 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.
- ggm 7y ago
  Yes. This is beautifully expressed. And 'hiring a russian interpreter' is almost always the right way to fix this kind of problem. POSIX would seem to me to be the russian interpreter of choice here. Is java a language which has no word for the colour green? in the sense where the eponymous russian interpreter has to say: "concept which cannot adequately be expressed in russian" or something 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
  - eesmith 7y ago
    It seems less than graceful to respond to articles which point out the existence and difficulty of problems by saying it's fixed. The entire point is to show how it's more difficult than many think, not elide the issues. What does POSIX have to do with anything? Eg, the tz database isn't POSIX.
    - ggm 7y ago
      The POSIX spec of date time specified conversions into a neutral form. Maybe it's C centric thinking but it felt like a problem which has existed and been solved by writing a 'russian interpreter' solution: convert the values on the edge to a canonical form and use functions which manipulate the canonical form. The TZ files i only mention because within the limit of modern epoch Times and dates they do a pretty good job of handling the minutia of what a local time means in any given period. 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.
bouke 7y ago
That’s not taking time zones into consideration, so might be off by an arbitrary amount of hours/minutes.
- ggm 7y ago
  Obviously you would set TZ before up-converting. I spoke in UTC about an input time I specified in UTC. POSIX date time models understand timezones and on well configured systems understand prior states of time zone behaviours at boundaries like summertime into historical past states. The 1990s USENET discussions did at one point veer off into rotational speed of the earth MYA ago, I'm not sure many people cared but astronomers maybe have to. (I don't think dinosoars used summertime)
  - bouke 7y ago
    Historically correct timezone handling is one thing, but you also have to consider future timezone changes unknown at this time. For example some EU countries might decide to cancel daylight savings. Now your conversion from UTC is off by an hour.
quickthrower2 7y ago
One does not simply ... convert time
coldtea 7y ago
That has its own tons of cans of worms... See: https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time https://infiniteundo.com/post/25326999628/falsehoods-program...
demurgos 7y ago
> I always convert time into time in seconds since the epoch 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.
- haberman 7y ago
  > A POSIX second corresponds to 1/(24 * 60 * 60) of a day. An SI second is defined using atomic time measurement. 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-leaping-seconds.html https://googleblog.blogspot.com/2011/09/time-technology-and-...) and now advocates making it standard (https://developers.google.com/time/smear 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.
  - demurgos 7y ago
    Yes, I definitely agree that the reality is even more complicated and there are different implementations. The recent time-smearing approach is closer to the POSIX standard [0]: > 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_chap04.html#tag_04_16 https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...

gambler 7y ago

> Things we take for granted are hard. Dates are hard, text is hard, graphics are even harder. We stand on the shoulders of giants. More like we stand on piles of broken shit. A lot of "hard" things in programming have very little fundamental complexity. They are hard because at some point in time someone made a compromise that no longer is relevant or makes any sense. It is possible to redesign those things to be simple, but modern developers are conditioned to fight this at every step. The idea that the first thing you should try to do when faced with extraordinary complexity is to bypass it is completely alien to people whose daily jobs consist of continuously banging their heads against convoluted frameworks and deficient APIs. Time handling is a great example. Until you get into general relativity, time itself is extremely simple and uniform. But human representations of time are extremely convoluted, because historically they are based on astronomy. Here is the kicker: 99.99% of all software has nothing to do with astronomy, and yet people chose to inject those complexities in core structures that track time. (For example, Unix timestamps have leap seconds, which is a source of innumerable bugs and ridiculous convolutions in code to prevent those bugs.)

stnmtn 7y ago
Are you arguing for trying to create a new method of tracking time instead of just including moment.js?
- hrktb 7y ago
  I read parent’s comment as a plea to be simple where it’s allowed. For instance use straight timestamps where there is no need for calendar manipulations. I am sympathic to this argument and I’d also totally join a movement to ignore DST or uncouple years from earth rotation
- m45t3r 7y ago
  This post sounds kinda like a satire: "we have problem X, did you try something.js to fix it?"
rovolo 7y ago
If by 'based on astronomy' you mean 'based on the sun' because the sun is a star, then I agree. But, plenty of software has lots to do with the sun because they have to interact with people, and people like to be synchronized with the sun. If you don't want software to interact with humans, or you only care about duration rather than human datetime, then go ahead and use UT1. However, as long as your interacting with people, you're going to need to fix people first. You should start with these primers if you're going to fix how humans interact with time: - https://qntm.org/abolish https://qntm.org/abolish - https://qntm.org/continuous https://qntm.org/continuous