Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

UTC Is Enough for Everyone, Right?

zachholman.com

Post reply on HN
Print view View original

161–170 of 321 posts

Re: UTC Is Enough for Everyone, Right?

#161

Post by pimlottc »

da_chicken wrote: post #47

> Properly storing timezone-aware times I'd just like to point out that a lot of RDBMSs support storing date and time alongside timezone information directly without using two separate fields. SQL Server has datetimeoffset, PostgreSQL has timestamp with time zone, and Oracle has timestamp with time zone. I think MySQL does as well, but I seem to recall something strange about it. Or maybe that's just me expecting MyS…

Implementations of time-and-time-zone different enough between databases, and languages, and libraries, etc that I believe it's worth storing them separately as the author suggests, both for simple clarity and to force the developer dealing with them to actually think about timezones. Even if the database gets it right in a single value, it's way too easy for the developer to read the field and ignore the timezone information without consideration.

Re: UTC Is Enough for Everyone, Right?

#162

Post by marshray »

There are only two types of time systems:

1. TAI, and systems that have a fixed 1-to-1 mapping to it (e.g., GPS).

2. Systems that are generally unable to calculate how many seconds will elapse until your next birthday. UTC is in this category.

Articles like this spend a lot of time on the varying degrees of insanity in category 2. But I would rather start with category 1 and negotiate any additional complexity from there.

Re: UTC Is Enough for Everyone, Right?

#163

Post by packet_nerd »

TylerE wrote: post #87
hinkley wrote: post #46

I have been thinking a lot lately that we are trying to solve class of XY Problem. Universal time is in part about trying to order events in a strict order. Probelm is, nobody observed that order. Later we infer things about the system based on this chronology but it’s completely fictitious and we have to stretch our brains to explain the state of the system. The Java Memory Model, and subsequently several other lang…

Every bank I've ever been a sucker-err-customer of seemed to use whichever order results in the most fees. Not the only reason I use a credit union these days.

Yep, transaction reordering to optimize fees is definitly a thing in the finance world. At least some Credit Unions do it too.

Re: UTC Is Enough for Everyone, Right?

#164

Post by cryptonector »

leonroy wrote: post #156
0x0 wrote: post #33

So the article seems to imply you should store all timestamps as UTC (with an additional timezone string ID). But for events in the future that needs to happen on a specific "wall clock point in time", it might be better to actually store the yyyy-mm-dd hh:mm:ss as a string with a timezone next to it, because timezones can and do change often unpredictably. If you pre-calculate what "4.00pm next August 1st" is as a U…

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

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.

Re: UTC Is Enough for Everyone, Right?

#165

Post by cryptonector »

senlutomchen wrote: post #155
Terr_ wrote: post #122

Earlier quoted context omitted.

IMO the biggest problem isn't the how you store information or even do the date-math. The most frustrating thing is drawing out user-intent, distinguishing between two use-cases which are so similar that most users won't even know what they want. Specifically, future events which aren't tied to a geographical location, and ones which are. And in the latter case, determining which single location it should be pegged t…

Another example of confusing user-intent is "last X days". I.e Does "Last 2 days" indicate: A. Last 48 hours? B. Yesterday + Today up to now C. Yesterday + the day before.

"One month from now" is horrible. Is that "30 days from now" or "same day number next month"? If the latter, then how do you handle a 31st when the next month has 30 days or fewer? (Or a 29th when the next month is February and this is not a leap year?)

This is a difficult subject.

Recurrence is especially tough to model in a database.

Re: UTC Is Enough for Everyone, Right?

#166

Post by amptorn »

leonroy wrote: post #156
0x0 wrote: post #33

So the article seems to imply you should store all timestamps as UTC (with an additional timezone string ID). But for events in the future that needs to happen on a specific "wall clock point in time", it might be better to actually store the yyyy-mm-dd hh:mm:ss as a string with a timezone next to it, because timezones can and do change often unpredictably. If you pre-calculate what "4.00pm next August 1st" is as a U…

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 another, somebody's 9 o'clock meeting is going to suddenly take place at 10. Having accepted that, we can push through the idealism and start working actual solutions like the one you described - have the user attach the regularly scheduled meeting time specifically to the UK or to the US.

Re: UTC Is Enough for Everyone, Right?

#167

Post by cryptonector »

bad_user wrote: post #78
0x0 wrote: post #33

So the article seems to imply you should store all timestamps as UTC (with an additional timezone string ID). But for events in the future that needs to happen on a specific "wall clock point in time", it might be better to actually store the yyyy-mm-dd hh:mm:ss as a string with a timezone next to it, because timezones can and do change often unpredictably. If you pre-calculate what "4.00pm next August 1st" is as a U…

Actually the meaning of a date like: 2018-05-26T13:45:21+02:00 Will never change, regardless how many time zone changes you may have. What does change is the method to compute the time difference. So can you say how many days, hours, minutes, seconds ago that was from: 2043-02-12T11:15:16+02:00 You won’t be able to, because then you have to account for leap seconds, etc. Also “next Tuesday” does have to take into acc…

But users want wall clock time. That you stored 2018-05-26T13:45:21+02:00 is irrelevant. The user wants that time to change if the original timezone's definition changes.

So you really need to store {datetime, timezone_name}.

It gets tricky when you don't know the timezone... For example, you're on a plane with your devices in airplane mode and no wifi connectivity, and you want to create a calendar event in destination time... The UI had better let you specify a TZ, and you'll have to know what it is. Whereas if you want until you land you can just let your devices figure out what TZ you're in and spare you the bother of thinking about it. That's an unlikely edge case, but the UI should really let you input a TZ if you want to. Perhaps the UI should insist on you entering a TZ if you're in airplane mode.

Re: UTC Is Enough for Everyone, Right?

#169

Post by john00088876 »

If you think calendar apps are a pain try television broadcast automation... frame accuracy instead of per second, with fractional frame rates (29.97, 23.98, fps) and a mix of content of different frame rates on the same playlist and conversion to different frame rate on the way out, plus operators in a different timezone than the channel and the need to handle timezone changes without messing things up on air.

I have nothing to do with it but this is an open source automation project I have bookmarked with some of those functions:

https://github.com/jaskie/PlayoutAutomation/blob/develop/TAS...

Lots of hassles.

Post reply on HN