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

91–96 of 96 posts

Re: How to save datetimes for future events

#91

Post by jrochkind1 »

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…

> 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?

Re: How to save datetimes for future events

#92

Post by developer1 »

yourapostasy wrote: post #4

Would it be possible to avoid any ambiguity at all by saving the timezone rules themselves as separate most-previous and current versions within the application context itself? Then when a new set of rules is detected (perhaps notification of updates at the OS level should be turned into a standardized publish-subscribe API to avoid too many applications polling for changes all the time, especially wasteful on batter…

This is the right solution. You don't check for any changes every single time you read out a timestamp - that's just unnecessary overhead and removes the ability to write simple queries to search for timestamps within a certain range.

You store the timestamp, and a foreign key to the timezone as it was defined at the time the timestamp was inserted (orginal revision). You then schedule a sweep (every day, say) that simple detects which timezones have received an actual update, then select/update any rows which were created with the previous timezone entry. Not very difficult to implement, and generates the minimal amount of overhead possible.

The only exception is the one raised by laut regarding an event scheduled for say 02:30, and where 02:30 simply does not exist after a rules update. The sweep can detect these and in theory should alert the user to the inconsistency. An annoying edge case to be sure. :/

Re: How to save datetimes for future events

#93

Post by angersock »

mark-r wrote: post #88
angersock wrote: post #80

Earlier quoted context omitted.

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.

Did you read the article? A specific case was presented where persisting in UTC simply won't work. I still believe that UTC is useful as an intermediary, and persisting in UTC can work if all your times are in the past and all your conversions are done with an up-to-date rule list.

Yeah, read the article. Considering new house rule of UTC for present and past, wall time (?) for future.

Person I was responding to gave bad reasoning ("Pick the timezone that matters most") instead of echoing what the article said.

Re: How to save datetimes for future events

#94

Post by taejo »

arielby wrote: post #85
laut wrote: post #66

Earlier quoted context omitted.

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.

UTC just provides a labeling for TAI/TT seconds, so a count-of-UTC-seconds timestamp is identical to a count-of-TAI-seconds timestamp (assuming the same epoch). Both are different from a count-of-non-leap-UTC-seconds aka POSIX time.

Yes, but we don't know what that labeling will be in the future.

Re: How to save datetimes for future events

#95

Post by laut »

dragonwriter wrote: post #34
mark-r wrote: post #25

Earlier quoted context omitted.

Why would the time for the Australian be incorrect? If the meeting organizer is in Chile, then the meeting time would be ruled by Chile's local clock. If the rule change affects the difference between Australia and Chile, then simply loading the updated rules on both sides should readjust things automatically - if the time was stored as Chile local, not UTC.

The fact that the meeting organizer in Chile does not imply that the key constraint for the meeting time was in Chile, rather than in the schedule of the Australian attendees. (Of course, its actually possible that there were essential constraints on both sides, in which case, the problem is more difficult, or that the key constraint was that the call needed to immediately precede or follow an event in a timezone dif…

If I enter "10:00 in Chile" in a calendar app I expect it to stay "10:00 in Chile". And not magically change to "11:00 in Chile". That is what the example was.

Re: How to save datetimes for future events

#96

Post by laut »

arielby wrote: post #85
laut wrote: post #66

Earlier quoted context omitted.

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.

UTC just provides a labeling for TAI/TT seconds, so a count-of-UTC-seconds timestamp is identical to a count-of-TAI-seconds timestamp (assuming the same epoch). Both are different from a count-of-non-leap-UTC-seconds aka POSIX time.

You cannot know for sure how many leap seconds there will be in for instance the next 5 years. So you cannot know for sure exactly how many seconds there will elapse from now until for instance July 1st 2020 midnight UTC.
Post reply on HN