How to save datetimes for future events • Hacker News Board

Re: How to save datetimes for future events

#51

Post by ldenneau » Mon, Mar 23, 2015, 6:43 PM UTC

This article is way overthinking it. It's better to simply store the UTC time of the event, and nothing else. Local time zone conversions can be done when displaying/editing. Presumably at the time you are reading your calendar, your local software knows the current rules to offset from GMT.

We have Skype meetings all the time involving parties in different US timezones and/or different countries. There's no "place" or local time zone for the meeting. We schedule in UTC and our local software or calendar program knows what time zone we are in to display the correct local time.

Re: How to save datetimes for future events

#52

Post by andrewfong » Mon, Mar 23, 2015, 6:55 PM UTC

ldenneau wrote: post #51

This article is way overthinking it. It's better to simply store the UTC time of the event, and nothing else. Local time zone conversions can be done when displaying/editing. Presumably at the time you are reading your calendar, your local software knows the current rules to offset from GMT. We have Skype meetings all the time involving parties in different US timezones and/or different countries. There's no "place"…

You missed the whole bit about the timezone rule changing in between when the event was last edited and when it was displayed.

Re: How to save datetimes for future events

#53

Post by tghw » Mon, Mar 23, 2015, 6:57 PM UTC

ldenneau wrote: post #51

This article is way overthinking it. It's better to simply store the UTC time of the event, and nothing else. Local time zone conversions can be done when displaying/editing. Presumably at the time you are reading your calendar, your local software knows the current rules to offset from GMT. We have Skype meetings all the time involving parties in different US timezones and/or different countries. There's no "place"…

I think you're missing the point of the article.

What he's getting at is that timezone rules change, so the function to go from local to UTC when you save the meeting is not the same as the function to go from UTC back to local at the time of the meeting.

Re: How to save datetimes for future events

#54

Post by mapgrep » Mon, Mar 23, 2015, 6:59 PM UTC

ldenneau wrote: post #51

This article is way overthinking it. It's better to simply store the UTC time of the event, and nothing else. Local time zone conversions can be done when displaying/editing. Presumably at the time you are reading your calendar, your local software knows the current rules to offset from GMT. We have Skype meetings all the time involving parties in different US timezones and/or different countries. There's no "place"…

"It's better to simply store the UTC time of the event, and nothing else."

The whole point of the article is that /you cannot know with certainty the UTC time of a future event/ if you are starting with a wallclock time in a particular location.

In this article, a 10:00 am meeting in Santiago has one UTC value prior to a new law, and a different UTC value after the new law.

If you are saying everyone should "schedule in UTC" like you do, good luck imposing that on the world!

Re: How to save datetimes for future events

#55

Post by laut » Mon, Mar 23, 2015, 7:00 PM UTC

ldenneau wrote: post #51

This article is way overthinking it. It's better to simply store the UTC time of the event, and nothing else. Local time zone conversions can be done when displaying/editing. Presumably at the time you are reading your calendar, your local software knows the current rules to offset from GMT. We have Skype meetings all the time involving parties in different US timezones and/or different countries. There's no "place"…

I don't think you understood the described problem with storing the time in UTC. In the example in the article it is assumed and your software gets the timezone update. But because the meeting is stored in UTC, it displays the wrong time.

The reason it works for you is because you schedule in UTC. That's great, but for people that don't schedule meetings in UTC, you are vulnerable to the problem described if you just save the time in UTC.

Do you schedule meetings with your dentist in UTC too? I'd wager that most meetings are not scheduled in UTC.

Re: How to save datetimes for future events

#56

Post by masklinn » Mon, Mar 23, 2015, 7:01 PM UTC

ldenneau wrote: post #51

This article is way overthinking it. It's better to simply store the UTC time of the event, and nothing else. Local time zone conversions can be done when displaying/editing. Presumably at the time you are reading your calendar, your local software knows the current rules to offset from GMT. We have Skype meetings all the time involving parties in different US timezones and/or different countries. There's no "place"…

You haven't actually read the article have you?

> It's better to simply store the UTC time of the event, and nothing else. Local time zone conversions can be done when displaying/editing.

That timezone conversion is the problem, the UTC offset of a physical location can change drastically with surprisingly little notice. You schedule a meeting on your calendar for 10AM, it's stored as XUTC, the rules changes now your calendar tells you your meeting is at 11AM local time, you've missed your meeting (because you were physically meeting your VC who uses their own calendar which does not have that specific issue).

And being an hour off is pretty tame, back in 2011 Samoa flipped across the international date line, if you had scheduled a meeting after the flip and it was stored in UTC but edited or viewed in local time you would now go to it a day off.

Re: How to save datetimes for future events

#57

Post by tmd83 » Mon, Mar 23, 2015, 7:02 PM UTC

protomyth wrote: post #49

curun1r wrote: post #46

Earlier quoted context omitted.

The problem with your solution is that while it solves the client-side of the equation, it creates a nightmare on the server-side. Imagine I need to send a reminder email to people an hour before their event. I now need to convert every saved time to the time on the server to know when to send that email. And I can't efficiently query the store of events since they're not stored in a uniform time format. I'd rather h…

"it creates a nightmare on the server-side" Actually, last time I used something like this the queries aren't really that bad on a server (to write or execute). Its a fairly easy set of relational queries (build current time at location table -> events) and I would rather take the time on the server versus the client. This is the kind of thing a relation database does quite well and user expectations must be met.

I have a feeling that you're oversimplifying it. You will have events/dates on the table which are even for a single timezone have multiple offset like before/after DST. Essentially you will have to store the whole timezone rule data in some table and dynamically query based on the time value of the date, location and corresponding tz rule. I believe it would be nightmare of a query. But even that maybe possible if you have to basically do this for one single event table and few queries. Try to do this kind of query for 100s of tables and thousands of date type of column and see how quickly it spirals out of control.

Re: How to save datetimes for future events

#58

Post by mark-r » Mon, Mar 23, 2015, 7:09 PM UTC

baddox wrote: post #48

> Instead of saving the time in UTC along with the time zone, developers can save what the user expects us to save: the wall time. Ie. what the clock on the wall will say. That's not at all foolproof, although it works for the case the author describes and probably works for most people most of the time. It wouldn't work if, for some reason, I'm entering a calendar event for something I know will happen exactly n hou…

In that case, go ahead and convert to UTC and save UTC as the relevant zone. In no case is timestamp+zone less flexible than UTC timestamp by itself.

Re: How to save datetimes for future events

#59

Post by protomyth » Mon, Mar 23, 2015, 7:15 PM UTC

tmd83 wrote: post #57

protomyth wrote: post #49

Earlier quoted context omitted.

"it creates a nightmare on the server-side" Actually, last time I used something like this the queries aren't really that bad on a server (to write or execute). Its a fairly easy set of relational queries (build current time at location table -> events) and I would rather take the time on the server versus the client. This is the kind of thing a relation database does quite well and user expectations must be met.

I have a feeling that you're oversimplifying it. You will have events/dates on the table which are even for a single timezone have multiple offset like before/after DST. Essentially you will have to store the whole timezone rule data in some table and dynamically query based on the time value of the date, location and corresponding tz rule. I believe it would be nightmare of a query. But even that maybe possible if y…

I think your over complicating the query. You split the location -> time zone -> offset into one query to a temp table (doesn't need to run each time - very easy to predicate needed updates) then do the local time / location part. Its really not that hard.

I should point out I'm in the SQL / Stored Procedure camp and not talking using some object mapping solution. That might get problematic.

Re: How to save datetimes for future events

#60

Post by mark-r » Mon, Mar 23, 2015, 7:16 PM UTC

ldenneau wrote: post #51

This article is way overthinking it. It's better to simply store the UTC time of the event, and nothing else. Local time zone conversions can be done when displaying/editing. Presumably at the time you are reading your calendar, your local software knows the current rules to offset from GMT. We have Skype meetings all the time involving parties in different US timezones and/or different countries. There's no "place"…

Until today, I thought the way you did and advocated the same principle whenever I could. This article changed my mind very quickly, all with a simple easy-to-understand example.

For any event you generally have a location or time zone that the event time is specified in. If that's UTC then great, you don't have a problem. Most people don't work in UTC; if the time zone laws change, then the event time in UTC will change too.