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

How to save datetimes for future events

creativedeletion.com

Post reply on HN
Print view View original

71–80 of 96 posts

Re: How to save datetimes for future events

#71

Post by SloopJon »

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

When I create a repeating event in Calendar for Mac in a Google calendar, the scheduled time changes after a DST transition. Really annoying.

Re: How to save datetimes for future events

#72

Post by protomyth »

fragmede wrote: post #69
protomyth wrote: post #30

For future events, you expect to schedule a meeting / appointment at [Local Time] on [Date] at [Location]. If a time change happens between now and the future event (e.g. daylight savings time), it doesn't matter from the perspective of the meeting because you have a fixed time. So, I would for future events record [Local Time], [Date], and [Location]. Then make sure I have a [Location] -> [Time Zone] table. [Local T…

DST is a whole stupid mess, as those doing business between the US and the UK have been painfully aware of over the past three weeks. There is an offset for daylights savings time, so three weeks ago the time difference between NYC and London was 5 hours, but two weeks ago it became 4 hours when US changed to summer time, and it'll be back to 5 next week. My 10 AM video conference from NYC with UK-based clients is on…

This is actually one of the fun problems because you have to be clear whose perspective and location is the important one.

"My 10 AM video conference from NYC with UK-based clients is on their schedule, so my meeting time changes to 11 AM in NYC"

The important location is the UK and the time on their schedule. You get floated to the proper local time.

"I schedule an in-person lunch meeting on Tuesday next week. I'm flying to London on Monday. The calender has to know my location has changed but that the lunch meeting is in-person, and to change the time appropriately."

The calendar has to know that the meeting is in London.

"The 'location' field could be set in the above cases to accommodate as a hack, but from a user experience perspective, the user's 'location' for a video conference is their conference room which is in their timezone, so 'location' isn't the best name."

Yeah, when talking to other programmers, location is fine, and location is fine for a lot of uses, but it does get murky on the communication aspect over the wire. Although the person scheduling it would probably be the location determinate for the appointment and the event notice would need to put that on the other participants calendar with the scheduler's location.

"All of the above can be handled with enough check-boxes and radio buttons in the user interface, but that makes your calender look ugly, complicated, and messy."

I don't think it actually would be that bad. It's more a rules engine thing. I think it might not be that bad. We just get mired in the complication when options aren't really that many from a user's point of view.

Re: How to save datetimes for future events

#73

Post by protomyth »

barrkel wrote: post #65
protomyth wrote: post #30

For future events, you expect to schedule a meeting / appointment at [Local Time] on [Date] at [Location]. If a time change happens between now and the future event (e.g. daylight savings time), it doesn't matter from the perspective of the meeting because you have a fixed time. So, I would for future events record [Local Time], [Date], and [Location]. Then make sure I have a [Location] -> [Time Zone] table. [Local T…

All too often, [Location] is something like a conference call, and is in fact in multiple different countries with different time zones and different rules. Deciding which location is the "primary" location should zone rules change is a social problem; whomever the other parties do not want to inconvenience the most wins. [Location] -> [Time Zone] isn't quite right either; you need a [Location, Date-Range] -> [Time Z…

Someone scheduled the conference call an that person would determine the location (or I will log in at X local time on Y date which should be attached to the event noticed and then figured out by my calendar).

Well, to get from [Location] -> [Time Zone] is a group of rules including the date.

UTC is nice for a lot of calculations, but it really isn't in a user's perspective.

Re: How to save datetimes for future events

#74

Post by curun1r »

protomyth wrote: post #59
tmd83 wrote: post #57

Earlier quoted context omitted.

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.

That's one way to handle it, but it still doesn't perform nearly as well simple greater/less/between where clauses, especially when you hit really large tables where you're going to want to index date values.

Since it's a fairly easy fix to update the way you do timezone conversions, it seems easier to put the logic there, where unit testing is easy, rather than in temp tables, stored procedures and query logic where testing is difficult and you've got state that needs to be carefully managed.

Re: How to save datetimes for future events

#75

Post by laut »

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…

The article is about saving datetimes. Usually calendars use datetime too.

If you need to count down X hours you are not looking to save a datetime. Maybe use an egg timer or the countdown feature of a smartphone.

Re: How to save datetimes for future events

#76

Post by laut »

fryguy wrote: post #23

Unfortunately, there's an ambiguity here. Suppose that you're going to watch the Super Bowl with your friends in Chile. So you set the appointment for 1830 local time in Chile. Then Chile changes their timezone, and your local time is wrong since the actual event is based on Eastern time, and not Chile time.

That is outside of the scope of the article. In this case you have to ask yourself. Do you want to save an appointment for 18:30 in Chile? Or for the Superbowl? You have to choose one.

If you really want to be sure tell your friends to use the timezone of the event. Maybe say "let's meet at 19:00 New York time" if the game starts at 20:00 in New York and you want to meet an hour before.

Re: How to save datetimes for future events

#77

Post by protomyth »

curun1r wrote: post #74
protomyth wrote: post #59

Earlier quoted context omitted.

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.

That's one way to handle it, but it still doesn't perform nearly as well simple greater/less/between where clauses, especially when you hit really large tables where you're going to want to index date values. Since it's a fairly easy fix to update the way you do timezone conversions, it seems easier to put the logic there, where unit testing is easy, rather than in temp tables, stored procedures and query logic where…

"but it still doesn't perform nearly as well simple greater/less/between where clauses"

I would have to write it, but I think the performance would be fine on a large dataset.

I have found that stored procedure and queries are quite easy to unit test. Particularly in this scenario where you can build simple input data and get out specific row(s). It is actually a lot easier than testing some Classes since you need to mock up sets of objects. With stored procedures and queries you can test the code in a harness without mocking up anything.

Re: How to save datetimes for future events

#78

Post by ldenneau »

tghw wrote: post #53
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.

I do get the point, but simply preserving the local time isn't the right answer. I'd argue that when you change your local timezone offset, then your future schedule is indeterminate and all events have to be reverified. What if the event is for an international flight -- is it still leaving or arriving at the same local time? How about that standing 9AM meeting -- is at 9 because of the corporate office in a different time zone calls in, so your local time breaks their calendar?

Re: How to save datetimes for future events

#79

Post by gravypod »

Why not just use a unix timestamp and convert to the local time format of all users? Is that a poor solution for this? Most unix timestamp to Date converters already take DST into account.

This also fixes the "MM/DD/YYYY", "DD/MM/YYYY", and "YYYY/MM/DD" fiasco as you can rely that the users computer is configured to the correct timezone/localization settings.

Re: How to save datetimes for future events

#80

Post by angersock »

logicuce wrote: post #38
protomyth wrote: post #30

For future events, you expect to schedule a meeting / appointment at [Local Time] on [Date] at [Location]. If a time change happens between now and the future event (e.g. daylight savings time), it doesn't matter from the perspective of the meeting because you have a fixed time. So, I would for future events record [Local Time], [Date], and [Location]. Then make sure I have a [Location] -> [Time Zone] table. [Local T…

Spot on. You don't need the UTC at all to be stored. What matters is the local time at the venue. If its a virtual meeting (eg. over Skype) with participants from multiple time zones, it is safe to assume always one time zone will take precedence over others and time should be saved with respect to that. If its a natural event like a solar eclipse, it can be saved in UTC. There is always one time zone in which the ev…

No no no--you will add a lot of hairball code if you persist in not UTC.

For the virtual meeting, you just localize the time as they query it--this will make your life vastly simpler when, for example, querying over an interval or what have you.

UTC is the right answer.

Post reply on HN