Live data from Hacker News

UTC Is Enough for Everyone, Right?

zachholman.com

231–240 of 321 posts

Re: UTC Is Enough for Everyone, Right?

#233

"Physicists are still debating on whether or not time actually exists in the universe." I'm not aware of any physicists debating this. If time didn't exist, there wouldn't be a physical dimension for it, and everything would be at a fixed position in 3-dimensional space.

>If time didn't exist, there wouldn't be a physical dimension for it, and everything would be at a fixed position in 3-dimensional space.

It's not necessarily the case. Maybe the universe is just an tangled graph of events. Maybe the dimensionality of spacetime only emerges as an asymptotic behavior of this graph and it breaks down in small scales. In this view time doesn't exist at a microscopic level.

Re: UTC Is Enough for Everyone, Right?

#234
post #88

In my 20 years of working with software and distributed architectures, no problems have been harder than working with time zones and calendars. It is truly nightmarish stuff. I am convinced you could run a very profitable consultancy specializing in debugging date and time related problems in people's systems.

Character encoding can be equally scary.

Re: UTC Is Enough for Everyone, Right?

#235

Earlier quoted context omitted.

We spent weeks on this for our new conference calling app to determine when a user says "Setup a call at 10am for my group every week" that come October 29th 2018 the call takes place at 10am, not 9am following a DST change. After a heckuva lotta research and reading we determined that we needed to store the scheduled meeting time using two values; the local datetime and the desired timezone eg. scheduledAt: 2018-05-…

This kind of thing becomes a lot of fun when you're trying to schedule a regular international call between e.g. the US and the UK, where the offset in hours changes four times per year because their daylight saving adjustments are not simultaneous. When I say "becomes a lot of fun" what I actually mean is that this observation lets us understand very quickly that the problem is not generally solvable. One way or ano…

> [..] regularly scheduled meeting time specifically to the UK or to the US

very funny things happen when there is a shared physical resource e.g. a booked meeting room, and you have a bunch of people schedule meetings with different reference time zones.

ah, and if you think this creates havoc only for a the few weeks while the TZs are out of sync, remember that in the southern hemisphere DST is applied in "reverse"

Re: UTC Is Enough for Everyone, Right?

#236

Earlier quoted context omitted.

This kind of thing becomes a lot of fun when you're trying to schedule a regular international call between e.g. the US and the UK, where the offset in hours changes four times per year because their daylight saving adjustments are not simultaneous. When I say "becomes a lot of fun" what I actually mean is that this observation lets us understand very quickly that the problem is not generally solvable. One way or ano…

> [..] regularly scheduled meeting time specifically to the UK or to the US very funny things happen when there is a shared physical resource e.g. a booked meeting room, and you have a bunch of people schedule meetings with different reference time zones. ah, and if you think this creates havoc only for a the few weeks while the TZs are out of sync, remember that in the southern hemisphere DST is applied in "reverse"

Oh, that's fun: "A change in the definition of a timezone has caused previously non-conflicting bookings to conflict."

Re: UTC Is Enough for Everyone, Right?

#237

We’re going to need a new data type: spacetime

I don't know if you were trying to make a joke or not, but you are absolutely right! With space travel, both are needed to tell time. Things get even more complicated quickly. Albeit, things like 15 minute timezone offsets from UTC will become a terrestrial problem.

Re: UTC Is Enough for Everyone, Right?

#239

Postgres have done a really good job here. It not only understands offsets (which most devs think are timezones) it also understands timezones. What's the difference? GMT-8 is an offset. America/New_York is a timezone. This becomes important when you want to schedule a meeting on the east coast of the USA in April - Europe and the US change DST on different dates. But if you tell postgres you want a time in a particu…

What's the point of unqualified offsets like that anyway? You either use UTC or a local time in the appropriate tz.

Useful when you need to store the offset of a specific event in the past where the timezone data doesn't matter. Especially logs since you want to know when it occured, so you store unqualified offset so the DoS attack doesn't suddenly happen an hour earlier than it says in the logs if DST happens between attack and the admin reading the log.

Re: UTC Is Enough for Everyone, Right?

#240
post #229

Earlier quoted context omitted.

You also need to periodically compute the next event, but you can't do it too far in advance. You have to do it close enough to the event that that you can adjust to timezone definition changes. Hopefully you don't have to think about leap seconds.

Why would anybody schedule events in local time to happen on leap seconds?

To make sure you covered those edge cases correctly!
Post reply on HN