Hacker News Reader

Comment by rkagerer | Hacker News Reader

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

[2] https://developers.google.com/time/smear

View on HN

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.

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.

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!)

It does, but, eh, I mean, read the accepted answer: apparently, the past is rather unpredictable.

> 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 :-/

That's interesting. Can you point to an example? Is it a resolution problem?

It’s a resolution problem if you want to measure something within 1s, which is fairly tame and reasonable.

Like, let's say you’re measuring the time between two events, and you’re logging a stream of them. If you use Unix timestamp, the timer will jump during a leap second.

This is because a day in Unix time is always exactly 86,400 “seconds”, but an actual civil day may be from 86,399 to 86,401 seconds. (It has never been 86,399 seconds, but it “could” be.)

So you should probably be using TAI. UTC is theoretically good enough but it is inconvenient to use because of the leap seconds. Unix time is a bit broken.

It is actually very easy to use TAI. You just need a GPS receiver. TAI is a fixed offset from GPS time (TAI = GPS + 19 seconds).

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_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.

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+Fin...

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?

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.

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...

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.

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). 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) :-)

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!

> 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

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.

“Isolines of sunrise on the globe” don’t exist/change with time of year. It’s more like there’s a “sunrise line” that runs around the globe, changing slowly with a one year period (ignoring lots of smaller effects)

If you really want to complicate things, a real “7 ‘o clock at local sunrise” clock should also be affected by local mountains.

If you really, really want to complicate things, include cloud cover, too, an require that sunrise must be observed (Muslims require that for the new moon to determine the end of Ramadan (https://en.wikipedia.org/wiki/Ramadan#Eid))

Huh? The sunrise line is what I was talking about.

The rest of that is hilarious. I have no interest to complicate things in those ways, but if you think those are good ideas, you should go for it! Propose them to your local government and try to get them to switch.

Zoom meeting with people in significantly different latitudes would be like meetings now with people in significantly different longitudes. The same mechanisms we use to cope with the latter should work with the former.

Time zones (even if daylight saving time switches aren’t synchronized) are a tamed version of synchronizing every clock with local sunrise. Things such as “Let’s meet next month, same time” wouldn’t make sense anymore.

Everybody would have to know what location a meeting is scheduled in. “An hour after sunrise in London” would be the same for everyone, but if you also meetings “two hours after sunrise in Madrid” and “three hours after sunrise in Paris”, how much time there is between them will vary during the year.

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.

> a regional time based on sunrise (which I'd put at 6 AM, probably).

So sunset at noon?

> 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.)

How would that change the fact that it took longer for the earth to spin back to the same place on its axis?

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.)

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.

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-...

There have been 27 leap seconds since the start of modern UTC in 1972. One second of time corresponds to 15 arcseconds of the earth’s rotation. 27 leap seconds corresponds to nearly 7 arcminutes of rotation, which is 7 nautical miles of distance at the equator. Would you like to re-do all maps to shift them 500 yards every time there is a leap second?

Considering that maps have to be re-done periodically to account for tectonic plate shifts anyway, maybe this idea isn't as far off-base as it sounds.

Since 2000, “Australia’s tectonic plate – the Earth’s fastest moving continental plate – has moved about 1.5 metres northeast (approximately 7 cm / yr)” https://www.icsm.gov.au/gda2020

That’s more than 1000 times slower than leapsecond-related drift

The geometry of plate movement isn't what affects the kind of apparent solar time changes that leap seconds address.

We do, however, take plate movement in to account when determining positions of things on the surface. Geodesic coordinate systems periodically publish 'Datum' that are the result of new surveys of positions. In some places, such as Australia, the difference a decade can make is pretty large. Other places, not so much.

Reply on news.ycombinator.com