6 ms·

The suggestions to use UTC are good, but that doesn't completely immunize you from all the weirdness of time. e.g. UTC still has leap seconds kludged in from t

The suggestions to use UTC are good, but that doesn't completely immunize you from all the weirdness of time. e.g. UTC still has leap seconds kludged in from time to time "because the Earth's rotation speed varies in response to climatic and geological events" [1]. There's been talk of redefining it at some point to remove them. GPS Time or Precision Time Protocol may be suitable when you need to measure events on a continuous scale. Leap smeared time used by Google and AWS is also an interesting topic [2]. [1] https://en.m.wikipedia.org/wiki/Leap_second https://en.m.wikipedia.org/wiki/Leap_second [2] https://developers.google.com/time/smear https://developers.google.com/time/smear

dahart 6y ago
Apparently days are slightly longer now (up to 0.06 microseconds) just in the last 10 year because of the enormous dam in China. 1 leap second every 16M years, I wonder if that’s enough to care about right now? https://en.wikipedia.org/wiki/Three_Gorges_Dam#Terrestrial_impact https://en.wikipedia.org/wiki/Three_Gorges_Dam#Terrestrial_i... Time smear is an interesting concept. Once enough of the world’s clocks are synced to online sources, I wonder if we should consider using that kind of idea to smear away daylight savings time over the whole year. Not sure it’s a great idea, but maybe it would be possible to set the sunrise to be 7am every day.
- fanf2 6y ago
  One of the earlier proposals for DST suggested shifting by 20 minutes four times in spring and back four times in autumn. Counting hours from sunrise or sunset (instead of noon) was common in the ancient world. (They were often rubber hours so there were always 12 hours of day and 12 of night regardless of the season.) Some years ago I sketched a way to do smoothed DST based on when the sun rises. The trick is to avoid time zone differences due to differences in latitude (as well as longitude). I chose to use sunrise at the nearest tropic as the benchmark, which gives you a gradual DST adjustment of about an hour and a half between winter and summer, changing by up to a minute or two each day. http://catless.ncl.ac.uk/Risks/search?query=Sunrise+time+Finch http://catless.ncl.ac.uk/Risks/search?query=Sunrise+time+Fin...
  - dahart 6y ago
    Yes exactly, I like this proposal! "The essential idea is that our clocks should be set using sunrise as a benchmark instead of noon." Are you pursuing it, and did you get any valuable feedback?
    - fanf2 6y ago
      Well, it was originally intended as satire (hence the reference to Jonathan Swift in the subject line) - even though its logic makes some kind of sense, it is completely impractical :-) I do have a bit of sketchy software that compares various times (local apparent solar time, local mean solar time, standard/daylight time, smoothed sunrise-based time, times of sunrise/noon/sunset) but I have never found a good enough reference for the astronomical calculations to be happy with it.
      - dahart 6y ago
        Oh jeez, hahaha whoosh, the joke went totally over my head - is that whole publication satire? Do you think it's becoming more likely to be practical over time? I'd guess it's still impractical, but the percent of the world's online-connected clocks has definitely skyrocketed in the last 10 years with the proliferation of smart phones...
        fanf2 6y ago
        RISKS is mostly sensible though it has a sense of humour especially around the 1st April :-) RISKS is one of the oldest mailing lists, since 1985, worth subscribing if you have an interest in computer systems security.
- Someone 6y ago
  Would that work well with zoom meetings where participants aren’t on the same latitude? I would think the difference in time of sunrise between them varies during the year (https://en.wikipedia.org/wiki/Sunrise_equation https://en.wikipedia.org/wiki/Sunrise_equation). If so, repeated appointments would have to move for at least one of them. In itself that isn’t problematic, but if one also has appointments with people on the same latitude, non-overlapping events might start overlapping over time. Also, why stop at sunrise, and discriminate against sunset? Do what the Romans did: always have 12 hours between sunrise and sunset and 12 between sunset and sunrise (https://en.wikipedia.org/wiki/Roman_timekeeping#Variation https://en.wikipedia.org/wiki/Roman_timekeeping#Variation) :-)
  - dahart 6y ago
    Oh yeah, I never even thought about latitudinal time zones! It could be a checkerboard. Or maybe we need diagonal stripes and not vertical stripes. Now I need to plot the isolines of sunrise on the globe... looks like I'm not getting anything done today... thanks! ;) Or I guess we could entrust the Google cloud to keep time and sync all the calendars. 12 hours of sun is a crazy idea, now that's some time smear. It'd be funny to try that in Iceland or Svalbard, where you'd end up with days where 12 hours are divided into 10 minutes... or worse, some days with no hours at all!
    - dmurray 6y ago
      > Now I need to plot the isolines of sunrise on the globe... looks like I'm not getting anything done today... thanks! ;) You can try different times on this page, for one: https://www.timeanddate.com/worldclock/sunearth.html https://www.timeanddate.com/worldclock/sunearth.html
      - dahart 6y ago
        Yes! There they are, the diagonal time zones. I don't know why I didn't check there. This website is so amazingly good, I keep referencing the interactive annual sunrise/sunset charts at different locations, just didn't think to check the world map. For some reason I feel like maybe the pastel colors and cartoony graphics make me frequently under-estimate how serious and thorough the charts and apps are here, but I am a big fan. Maybe time to donate.
- tzs 6y ago
  I think it could work to have a dual time system, with a worldwide time (probably UTC) used when you are trying to coordinate things with people who are not in your general region and a regional time based on sunrise (which I'd put at 6 AM, probably). Most people would have their clocks/watches/devices display regional time, or both regional and world time. Things like business hours, school hours, meal times, regional transit schedules, and other things that mostly just involve coordinating with people in the region would use regional time. For most people in a region, this would allow them to operate on a schedule that involves waking naturally to the brightening morning instead of using an alarm. It would also mean that all of the extra daylight hours that come with the summer would end up at the end of the day, instead of some of them going before you go to work or in more northern places even before you wake up.
  - iso1210 6y ago
    > a regional time based on sunrise (which I'd put at 6 AM, probably). So sunset at noon?
em500 6y ago
UTC or Unix epoch are good for datetimes in the past, e.g. for logging events. They're not good for future datetimes, e.g. for recording appointments. Because in case of local timezone policy changes, in the vast majority of cases the intention is for the future event to stay constant in the local timezone, and be changed in UTC / epoch. If for example you made the mistake of storing store opening hours in UTC and translate it to local time in the UI, you will be showing the wrong time. For appointments, you need both the datetime and the location/timezone. In case of cross-timezone appointments, e.g. virtual meetings, if there are timezone policy changes the issue cannot be resolved without rescheduling the event for some participants.
- Joker_vD 6y ago
  And for the event in the past, respectively, you need datetime and the then-effective offset, not timezone, if you want to know the "what was the local time on the actual physical wall clock?". Unless you're sure the tzdata were correct when the timestamp was taken, and your current tzdata have correct historical info, you can't just take UTC timestamp+timezone and convert it to local time. And I've seen enough machines that had deliberately wrong timezones for some time.
  - kevinmgranger 6y ago
    Doesn't the olson DB track when offsets changed based on UTC time, and thus UTC timestamp+timezone is enough? (If your datetime library handles historical information in the DB correctly, that is!)
    - Joker_vD 6y ago
      It does, but, eh, I mean, read the accepted answer: apparently, the past is rather unpredictable.
- klodolph 6y ago
  > UTC or Unix epoch are good for datetimes in the past, e.g. for logging events. Unix epoch is known not to be good enough for some scientific applications :-/
amelius 6y ago
> UTC still has leap seconds kludged in from time to time "because the Earth's rotation speed varies in response to climatic and geological events" Why do we adjust time, and not geometry (given that geometry changes anyway because of shifting of tectonic plates)? (By geometry I mean coordinates of objects like buildings, landmarks, etc.)
- bobthepanda 6y ago
  How would that change the fact that it took longer for the earth to spin back to the same place on its axis?
  - amelius 6y ago
    I mean, instead of adjusting the time, you adjust the coordinates. So Greenwich would move a bit and the real origin of UTC would be a little to the left or right of Greenwich. (We'll have to adjust it anyway because of tectonic plate shifting.)
    - teraflop 6y ago
      Whenever you see a UTC time, the timestamp itself tells you how which "leap second epoch" it falls into (with the exception of instants that fall within the leap second itself). The only extra information you need to correctly do time calculations is the table of leap seconds, and that's a very small amount of mostly-static data that everyone can agree on. With your proposal, time handling would be slightly simpler, but every geographic coordinate everywhere would need to be tagged with a date to let you know which epoch it was relative to, or else you would get huge (in local terms) errors.
- ooOOoo 6y ago
  The geometry used for maps actually changes because of shifting of tectonic plates! See https://nautil.us/issue/81/maps/what-happens-to-google-maps-when-tectonic-plates-move https://nautil.us/issue/81/maps/what-happens-to-google-maps-...
- fanf2 6y ago

dahart 6y ago

Apparently days are slightly longer now (up to 0.06 microseconds) just in the last 10 year because of the enormous dam in China. 1 leap second every 16M years, I wonder if that’s enough to care about right now? https://en.wikipedia.org/wiki/Three_Gorges_Dam#Terrestrial_impact https://en.wikipedia.org/wiki/Three_Gorges_Dam#Terrestrial_i... Time smear is an interesting concept. Once enough of the world’s clocks are synced to online sources, I wonder if we should consider using that kind of idea to smear away daylight savings time over the whole year. Not sure it’s a great idea, but maybe it would be possible to set the sunrise to be 7am every day.

fanf2 6y ago
One of the earlier proposals for DST suggested shifting by 20 minutes four times in spring and back four times in autumn. Counting hours from sunrise or sunset (instead of noon) was common in the ancient world. (They were often rubber hours so there were always 12 hours of day and 12 of night regardless of the season.) Some years ago I sketched a way to do smoothed DST based on when the sun rises. The trick is to avoid time zone differences due to differences in latitude (as well as longitude). I chose to use sunrise at the nearest tropic as the benchmark, which gives you a gradual DST adjustment of about an hour and a half between winter and summer, changing by up to a minute or two each day. http://catless.ncl.ac.uk/Risks/search?query=Sunrise+time+Finch http://catless.ncl.ac.uk/Risks/search?query=Sunrise+time+Fin...
- dahart 6y ago
  Yes exactly, I like this proposal! "The essential idea is that our clocks should be set using sunrise as a benchmark instead of noon." Are you pursuing it, and did you get any valuable feedback?
  - fanf2 6y ago
    Well, it was originally intended as satire (hence the reference to Jonathan Swift in the subject line) - even though its logic makes some kind of sense, it is completely impractical :-) I do have a bit of sketchy software that compares various times (local apparent solar time, local mean solar time, standard/daylight time, smoothed sunrise-based time, times of sunrise/noon/sunset) but I have never found a good enough reference for the astronomical calculations to be happy with it.
    - dahart 6y ago
      Oh jeez, hahaha whoosh, the joke went totally over my head - is that whole publication satire? Do you think it's becoming more likely to be practical over time? I'd guess it's still impractical, but the percent of the world's online-connected clocks has definitely skyrocketed in the last 10 years with the proliferation of smart phones...
      - fanf2 6y ago
        RISKS is mostly sensible though it has a sense of humour especially around the 1st April :-) RISKS is one of the oldest mailing lists, since 1985, worth subscribing if you have an interest in computer systems security.
Someone 6y ago
Would that work well with zoom meetings where participants aren’t on the same latitude? I would think the difference in time of sunrise between them varies during the year (https://en.wikipedia.org/wiki/Sunrise_equation https://en.wikipedia.org/wiki/Sunrise_equation). If so, repeated appointments would have to move for at least one of them. In itself that isn’t problematic, but if one also has appointments with people on the same latitude, non-overlapping events might start overlapping over time. Also, why stop at sunrise, and discriminate against sunset? Do what the Romans did: always have 12 hours between sunrise and sunset and 12 between sunset and sunrise (https://en.wikipedia.org/wiki/Roman_timekeeping#Variation https://en.wikipedia.org/wiki/Roman_timekeeping#Variation) :-)
- dahart 6y ago
  Oh yeah, I never even thought about latitudinal time zones! It could be a checkerboard. Or maybe we need diagonal stripes and not vertical stripes. Now I need to plot the isolines of sunrise on the globe... looks like I'm not getting anything done today... thanks! ;) Or I guess we could entrust the Google cloud to keep time and sync all the calendars. 12 hours of sun is a crazy idea, now that's some time smear. It'd be funny to try that in Iceland or Svalbard, where you'd end up with days where 12 hours are divided into 10 minutes... or worse, some days with no hours at all!
  - dmurray 6y ago
    > Now I need to plot the isolines of sunrise on the globe... looks like I'm not getting anything done today... thanks! ;) You can try different times on this page, for one: https://www.timeanddate.com/worldclock/sunearth.html https://www.timeanddate.com/worldclock/sunearth.html
    - dahart 6y ago
      Yes! There they are, the diagonal time zones. I don't know why I didn't check there. This website is so amazingly good, I keep referencing the interactive annual sunrise/sunset charts at different locations, just didn't think to check the world map. For some reason I feel like maybe the pastel colors and cartoony graphics make me frequently under-estimate how serious and thorough the charts and apps are here, but I am a big fan. Maybe time to donate.
tzs 6y ago
I think it could work to have a dual time system, with a worldwide time (probably UTC) used when you are trying to coordinate things with people who are not in your general region and a regional time based on sunrise (which I'd put at 6 AM, probably). Most people would have their clocks/watches/devices display regional time, or both regional and world time. Things like business hours, school hours, meal times, regional transit schedules, and other things that mostly just involve coordinating with people in the region would use regional time. For most people in a region, this would allow them to operate on a schedule that involves waking naturally to the brightening morning instead of using an alarm. It would also mean that all of the extra daylight hours that come with the summer would end up at the end of the day, instead of some of them going before you go to work or in more northern places even before you wake up.
- iso1210 6y ago
  > a regional time based on sunrise (which I'd put at 6 AM, probably). So sunset at noon?

em500 6y ago

UTC or Unix epoch are good for datetimes in the past, e.g. for logging events. They're not good for future datetimes, e.g. for recording appointments. Because in case of local timezone policy changes, in the vast majority of cases the intention is for the future event to stay constant in the local timezone, and be changed in UTC / epoch. If for example you made the mistake of storing store opening hours in UTC and translate it to local time in the UI, you will be showing the wrong time. For appointments, you need both the datetime and the location/timezone. In case of cross-timezone appointments, e.g. virtual meetings, if there are timezone policy changes the issue cannot be resolved without rescheduling the event for some participants.

Joker_vD 6y ago
And for the event in the past, respectively, you need datetime and the then-effective offset, not timezone, if you want to know the "what was the local time on the actual physical wall clock?". Unless you're sure the tzdata were correct when the timestamp was taken, and your current tzdata have correct historical info, you can't just take UTC timestamp+timezone and convert it to local time. And I've seen enough machines that had deliberately wrong timezones for some time.
- kevinmgranger 6y ago
  Doesn't the olson DB track when offsets changed based on UTC time, and thus UTC timestamp+timezone is enough? (If your datetime library handles historical information in the DB correctly, that is!)
  - Joker_vD 6y ago
    It does, but, eh, I mean, read the accepted answer: apparently, the past is rather unpredictable.
klodolph 6y ago
> UTC or Unix epoch are good for datetimes in the past, e.g. for logging events. Unix epoch is known not to be good enough for some scientific applications :-/

amelius 6y ago

> UTC still has leap seconds kludged in from time to time "because the Earth's rotation speed varies in response to climatic and geological events" Why do we adjust time, and not geometry (given that geometry changes anyway because of shifting of tectonic plates)? (By geometry I mean coordinates of objects like buildings, landmarks, etc.)

bobthepanda 6y ago
How would that change the fact that it took longer for the earth to spin back to the same place on its axis?
- amelius 6y ago
  I mean, instead of adjusting the time, you adjust the coordinates. So Greenwich would move a bit and the real origin of UTC would be a little to the left or right of Greenwich. (We'll have to adjust it anyway because of tectonic plate shifting.)
  - teraflop 6y ago
    Whenever you see a UTC time, the timestamp itself tells you how which "leap second epoch" it falls into (with the exception of instants that fall within the leap second itself). The only extra information you need to correctly do time calculations is the table of leap seconds, and that's a very small amount of mostly-static data that everyone can agree on. With your proposal, time handling would be slightly simpler, but every geographic coordinate everywhere would need to be tagged with a date to let you know which epoch it was relative to, or else you would get huge (in local terms) errors.
ooOOoo 6y ago
The geometry used for maps actually changes because of shifting of tectonic plates! See https://nautil.us/issue/81/maps/what-happens-to-google-maps-when-tectonic-plates-move https://nautil.us/issue/81/maps/what-happens-to-google-maps-...
fanf2 6y ago