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

81–90 of 96 posts

Re: How to save datetimes for future events

#81

Post by jrochkind1 »

Am I missing something, or does their solution not actually solve their specific example problem case at all?

Saving local time plus offset is _exactly_ the same information as saving GMT, isn't it?

You'd really need to save local datetime plus location... which they don't seem to actually be recommending?

Of course, for actually triggering an alarm or whatever, you'd still need to plot this on the actual timeline somehow, and deal with periodically checking to see if it should be changed because of a DST or timezone rule change or whatever.

Re: How to save datetimes for future events

#82

Post by andrewfong »

gravypod wrote: post #79

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.

Because the Unix timestamp is based on UTC and may not accurately capture the user's intent if the DST rules change in between when the timestamp is created and when the timestamp is read.

That is, suppose I schedule an event on 2016 April 1, at 10am in San Francisco, California. Under current DST rules, this translates into 2016 April 1, 5pm UTC or a Unix timestamp of 1459530000.

Now suppose DST is abolished in California between now and the event occurring. A Unix timestamp of 1459530000 would then correspond to 2016 April 1, at 9am in San Francisco, which is one hour too early.

Another way to think about this: You have to apply the DST conversion rules applicable at the time the event was created, NOT the (potentially different) rules at the time the event occurs. But maintaining different sets of conversion rules based on when an event is scheduled is a lot more cumbersome than simply recording the local time and location.

Re: How to save datetimes for future events

#83

Post by marcosdumay »

protomyth wrote: post #72
fragmede wrote: post #69

Earlier quoted context omitted.

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

Options are change the time or not.

Yet, your rules engine will be kilobytes long, and catch the users by surprise about half the time - because, let's face it, this is completely context sensitive and thus can not be predicted by your software.

Re: How to save datetimes for future events

#84

Post by laut »

jrochkind1 wrote: post #81

Am I missing something, or does their solution not actually solve their specific example problem case at all? Saving local time plus offset is _exactly_ the same information as saving GMT, isn't it? You'd really need to save local datetime plus location... which they don't seem to actually be recommending? Of course, for actually triggering an alarm or whatever, you'd still need to plot this on the actual timeline so…

The important part is local time plus timezone.

The offset is there only for the very rare case that you save a time that you know is ambiguous when you save it. And when DST rules don't change. Usually it happens when you change from DST to non-DST in the autumn and a certain hour happens twice.

In the example, the offset will not be used. Only local time plus time zone.

edit: I have updated the article to explain this part.

Re: How to save datetimes for future events

#85

Post by arielby »

laut wrote: post #66
VBprogrammer wrote: post #50

Earlier quoted context omitted.

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.

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.

Re: How to save datetimes for future events

#86

Post by NamTaf »

What about saving the present time (the datetime when the information is recorded) and the time offset as calculated at that moment? In theory then it doesn't matter what happens, you're still able to adjust. The only ambiguity I can think of is if leap (seconds|hours|days) are introduced, but surely you just add them on to the delta too?

Of course, this system fails when you suddenly travel anything approaching relativistic speeds, but I guess you could save your time delta as a velocity-time delta :)

Edit: I'm not actually advocating this as a solution, I just found it an interesting thought experiment.

Re: How to save datetimes for future events

#87

Post by mark-r »

NamTaf wrote: post #86

What about saving the present time (the datetime when the information is recorded) and the time offset as calculated at that moment? In theory then it doesn't matter what happens, you're still able to adjust. The only ambiguity I can think of is if leap (seconds|hours|days) are introduced, but surely you just add them on to the delta too? Of course, this system fails when you suddenly travel anything approaching rela…

Time offset by itself isn't sufficient to know if the rules for calculating that time offset have changed. You need to know the rules themselves, and the easiest way to record that is with a time zone.

Re: How to save datetimes for future events

#88

Post by mark-r »

angersock wrote: post #80
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…

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.

Re: How to save datetimes for future events

#90

Post by edejong »

protomyth wrote: post #77
curun1r wrote: post #74

Earlier quoted context omitted.

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…

I think it would be impossible to get good performance using normal (one dimensional) indices.

The problem is, when your time-zone information changes, you'd need to recalculate all your materialized views. Most popular databases lock the index/materialized view when it is being rebuild, blocking all access. When your tables are in the order of 1B rows, you can't really afford that.

Post reply on HN