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

241–250 of 321 posts

Re: UTC Is Enough for Everyone, Right?

#241

Post by erpellan »

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…

It gets even more fun if you need to answer questions like: "When this event was scheduled 6 months ago for today at 2pm, what UTC time did that represent then vs now?". Timezone rules also change. So when you're dealing with past and future you might also need the timestamp of the timestamp!

Re: UTC Is Enough for Everyone, Right?

#242

Post by simonh »

acqq wrote: post #229
cryptonector wrote: post #164

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?

If it's say a scheduler for an application, you might have an activity that occurs every x seconds. At a previous job events like that were often scheduled such that x was a different prime number for each task, in order to minimize regular simultaneous executions. A system like that could easily end up with tasks running on a leap-second.

Re: UTC Is Enough for Everyone, Right?

#243

Post by masklinn »

erpellan wrote: post #132

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…

How do you update the tzdb?

Re: UTC Is Enough for Everyone, Right?

#244

Post by tialaramex »

perl4ever wrote: post #226
tialaramex wrote: post #178

Earlier quoted context omitted.

"That scares me. Users really need wall clock time." Why would getting rid of leap seconds from UTC be a problem for that? The reason there are leap seconds is nothing to do with wall clock time, it's because some people feel the time ought to be intimately connected to the Earth's rotation, but the Earth doesn't oblige by rotating steadily. In my view the people demanding this relationship be maintained ought to tak…

I don't understand why you say leap seconds have nothing to do with wall clock time. Don't wall clocks include leap seconds?

Wall clocks just track UTC. Today they have leap seconds because we defined UTC to include leap seconds, tomorrow if UTC or a replacement universal time no longer has leap seconds then wall clocks won't have leap seconds.

Re: UTC Is Enough for Everyone, Right?

#247

Post by leonroy »

amptorn wrote: post #166
leonroy wrote: post #156

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…

> This kind of thing becomes a lot of fun when you're trying to schedule a regular international call

Heheh, exactly. We're currently debating how best to implement this since this one is more a UI issue than a UTC/Time issue.

For example if the user wants to schedule a call at 2pm New York time (UTC-4) we need to show them the consequences of dialling a participant in the UK (UTC+1) and even more so someone in Sydney (UTC+10).

If you use your ZonedDateTime classes carefully in your code (or equivalents if not using Java) then your app does take care of the DST changes. You can then show the user the scheduled time for not just the person making the creating the event but for every participant - ultimately the user has to decide what compromise to make when scheduling events across time zones and DST changes.

Re: UTC Is Enough for Everyone, Right?

#248

Post by narag »

cryptonector wrote: post #165
senlutomchen wrote: post #155

Earlier quoted context omitted.

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.

It depends on the context. I've programmed date logic for holiday calculation, days open for business and deadlines. I like working with dates because it's always well specified.

Re: UTC Is Enough for Everyone, Right?

#249

Post by narag »

erpellan wrote: post #241
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…

It gets even more fun if you need to answer questions like: "When this event was scheduled 6 months ago for today at 2pm, what UTC time did that represent then vs now?". Timezone rules also change. So when you're dealing with past and future you might also need the timestamp of the timestamp!

Exactly, storing both the universal time and the legal local time.

Re: UTC Is Enough for Everyone, Right?

#250

Post by Asooka »

matt-tingen wrote: post #172
senlutomchen wrote: post #155

Earlier quoted context omitted.

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.

Even something as simple as "tomorrow" can be ambiguous. I often ask my phone to set a reminder for tomorrow. If I'm asking after midnight, what I really mean is "today" since I haven't gone to sleep yet. Google seems to get this right, thankfully.

Tomorrow is tied to the morrow, so it isn't tomorrow until sunrise.
Post reply on HN