How to save datetimes for future events

Re:How to save datetimes for future events by kbenson on Monday March 23, 2015 @12:28PM (#9251722)

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 expect local (relative) time, we need to deliver that." That's not always right. There are plenty of cases where the user really wants absolute time. Fro example, when scheduling an international meeting where the other side is dictating the time. When timing a broadcast from another country. Really, any time when you need to deal with events scheduled outside your local time, or have components (or people) that run on times that are not local to you.

It gets trickier. What if you are tracking that international event, and that locality changes their time rules? For example, what if I'm in the US, and I wanted to schedule a time to watch a sporting event in Chile, and I scheduled it before the changed mentioned in the article? Whether I store it as a local time or an absolute time, it's wrong.

Really, you need three pieces of information. The UTC time representation, the timezone offset it applies to, and whether it should be treated as an absolute or localized time.

Edit: Corrected what type of stored offset needs to be kept

[ Parent | on HN ]

Re:How to save datetimes for future events by mark-r on Monday March 23, 2015 @12:31PM (#9251741)

If you stored it as your local time, it would be wrong. If you stored it as Chile's local time, it would be correct. The trick is to simply record the appropriate time zone along with the timestamp.

[ Parent | on HN ]

Re:How to save datetimes for future events by kevin_thibedeau on Monday March 23, 2015 @12:54PM (#9251875)

There is still the problem of handling the effects of DST on repeating events. You have to know the base UTC offset and any additional seasonal offset for the local zone. Then it becomes an issue if you travel to a different locality that doesn't observe DST.

[ Parent | on HN ]

Re:How to save datetimes for future events by kbenson on Monday March 23, 2015 @12:37PM (#9251762)

Absolutely correct. I was thinking that, even if we words said something else. :/ I've updated the last paragraph to reflect that.

[ Parent | on HN ]

Re:How to save datetimes for future events by tmd83 on Monday March 23, 2015 @03:22PM (#9252853)

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.

[ Parent | on HN ]

Re:How to save datetimes for future events by jrochkind1 on Monday March 23, 2015 @10:08PM (#9254494)

> There are plenty of cases where the user really wants absolute time. Fro example, when scheduling an international meeting where the other side is dictating the time.

Nope. Then you want local time _on the other party's side_, which has the same problematic relationship to 'absolute time'. I'm not sure there's any case (except scientists doing science) where the user would really want "absolute time" (and then we could ask _what_ absolute time, there isn't even neccesarily such a thing as One True Absolute Time).

> It gets trickier. What if you are tracking that international event, and that locality changes their time rules?

So, did you read the OP? That's in fact what the article is about?

[ Parent | on HN ]