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

61–70 of 96 posts

Re: How to save datetimes for future events

#61

Post by tmd83 »

kbenson wrote: post #26

This comes from mismatched expectations of what users are storing. Often they think, or assume without thinking, that they are storing a localized time. For ease of implementation, or just because the developer doesn't know any better, we often store in absolute time (UTC) with an offset and call it done. The problem is, nobody really thinks about this stuff. It's easy to pick out an error case and say "The users exp…

I never realised this problem despite having to work with some datetime problems before. But as you said the solution is not full proof. The biggest problem with your (what I believe is theoretically foolproof solution) is that it will for practical consideration. Most users will be unable to understand the complexity of the issue to properly choose whether to set the absolute/localized time or even which offset to apply in a lot cases. In case of some events one might not even know or find it hard to decide which timezone should be the primary timezone for the event or it might even change.

I think in terms of user understanding is to use one timezone (also shown to the user) to generate the UTC time and later if any changes happen to the timezone of the event or the corresponding user's timezone warn the user and ask for each event (maybe even in bulk) whether to

1. Keep the original walltime in the timezone (in case this is the deciding timezone) this will imply changes for users in other timezone.

And at this point some calculation figures out how to adjust the UTC.

2. Ignore the timezone change and keep the original offset.

3. Manually update.

Re: How to save datetimes for future events

#62

Post by mark-r »

icebraining wrote: post #47
mark-r wrote: post #27

Earlier quoted context omitted.

You simply need to observe the rule that event times should be specified in the time zone of the event itself. If the event is a meeting, then the meeting organizer will be in charge of setting the appropriate time zone.

That doesn't sound simple for the user at all. If I'm meeting locally with friends to see the game/oscars/wtv, I don't know or care about the time in the original timezone. My local TV guide / newspaper shows it in local time, and that's what everyone in the meeting cares about, so why would I set it to a completely different TZ?

Admittedly setting a time zone different than your local zone is an edge case. 99% of the time your local zone is the correct default. It would come up if you're scheduling a meeting for your trip to a different zone, or setting your TV to record the football game being broadcast from Chile.

Re: How to save datetimes for future events

#63

Post by tantalor »

Another solution is "floating time" which disregards timezones entirely. This is an option in iCalendar datetime formats.

In floating time, 10:00 in Chile is "10:00 in Chile". No timezone offset.

https://www.ietf.org/rfc/rfc2445.txt

https://scottworldblog.wordpress.com/2009/02/20/how-to-miss-...

Re: How to save datetimes for future events

#64

Post by mark-r »

protomyth wrote: post #44
logicuce wrote: post #38

Earlier quoted context omitted.

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…

"There is always one time zone in which the event won't be adjusted. Just use that." I agree with everything except I would modify that statement to be "There is always one location in the which the event won't be adjusted. Just use that." It seems like people are assuming time zone is fixed when it can change. The fixed point is the location which is used to determine the time zone. Natural events are trickier becau…

You're correct, the relation between time zones and locations isn't fixed. Unfortunately the time zone databases don't have enough granularity, you're forced to choose the nearest location that shares your current time zone.

Re: How to save datetimes for future events

#65

Post by barrkel »

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 Zone] table.

For sure, UTC is a beguiling trap for a programmer-oriented view of the world.

Re: How to save datetimes for future events

#66

Post by laut »

VBprogrammer wrote: post #50
laut wrote: post #5

Earlier quoted context omitted.

The problem is that the meeting time is defined in terms of the "wall time" in Chile. So if you store the time in terms of UTC, then you are going to have problems when the relation between UTC and the Santiago/Chile timezone changes. The computer in the example has the time wrong because it stored the time in UTC.

Well, it has it wrong, depending on what you are using it for. If you are putting in a calendar entry for the next predicted Lunar eclipse storing them in anything but UTC is wrong.

TAI would be better than UTC for the next Lunar eclipse in case you want to be exact to the second ;)

But yes, if you schedule the meeting in UTC, use UTC. The point is not to convert from non-UTC to UTC.

Re: How to save datetimes for future events

#67

Post by tmd83 »

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.

Not sure I understand the temp table part. My point was that you are always calculating it dynamically. So if you have two dates in location x, timezone y and you save the rows

time1, x = time1, ytimezone, yoffset

time2, x = time2, ytimezone, yoffset

but given the timezone rule change time1, ytimezone has an offset of z1, time2, ytimezone has z2 offset. Now you have to compare the 'time' against the validity period of each offset dynamically in the query. You can I guess get away with also storing the UTC additionally and schedule recalculate on timezone rule change.

But even then the ambiguity of which timezone to actually apply remains as mentioned in other comments.

Re: How to save datetimes for future events

#68

Post by protomyth »

tmd83 wrote: post #67
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.

Not sure I understand the temp table part. My point was that you are always calculating it dynamically. So if you have two dates in location x, timezone y and you save the rows time1, x = time1, ytimezone, yoffset time2, x = time2, ytimezone, yoffset but given the timezone rule change time1, ytimezone has an offset of z1, time2, ytimezone has z2 offset. Now you have to compare the 'time' against the validity period o…

"My point was that you are always calculating it dynamically."

My point is that you aren't. Location -> Time Zone -> Offset is something that only has to be updated infrequently. The results are then stored in a temp or work table (whatever optimizes better). Now I have a table with (Location, Local Event Time) which I can do a range on the offset query to get the Local Times. I would write the schema and queries, but this depends on which database you use. I've done this on Sybase 12.5 and it worked just fine.

"But even then the ambiguity of which timezone to actually apply remains as mentioned in other comments."

No, I have the wanted local time at a location.

Re: How to save datetimes for future events

#69

Post by fragmede »

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 their schedule, so my meeting time changes to 11 AM in NYC.

However, the UK localization team reports to me, so my 9 AM meeting with them is still at 9AM for me. Their meeting time changes, not mine.

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 '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.

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.

Re: How to save datetimes for future events

#70

Post by protomyth »

mark-r wrote: post #64
protomyth wrote: post #44

Earlier quoted context omitted.

"There is always one time zone in which the event won't be adjusted. Just use that." I agree with everything except I would modify that statement to be "There is always one location in the which the event won't be adjusted. Just use that." It seems like people are assuming time zone is fixed when it can change. The fixed point is the location which is used to determine the time zone. Natural events are trickier becau…

You're correct, the relation between time zones and locations isn't fixed. Unfortunately the time zone databases don't have enough granularity, you're forced to choose the nearest location that shares your current time zone.

I do love picking Minneapolis or Chicago when I want a ND location (look at North Dakota in the TZ database, we have some funky stuff going on). Looks like this question has some API for that http://stackoverflow.com/questions/16086962/how-to-get-a-tim...
Post reply on HN