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

UTC Is Enough for Everyone, Right?

zachholman.com

Post reply on HN
Print view View original

151–160 of 321 posts

Re: UTC Is Enough for Everyone, Right?

#151

Post by jgtrosh »

derefr wrote: post #149
0x0 wrote: post #33

So the article seems to imply you should store all timestamps as UTC (with an additional timezone string ID). But for events in the future that needs to happen on a specific "wall clock point in time", it might be better to actually store the yyyy-mm-dd hh:mm:ss as a string with a timezone next to it, because timezones can and do change often unpredictably. If you pre-calculate what "4.00pm next August 1st" is as a U…

Depends. Some things need to happen N seconds from now. Other things (usually things involving humans) need to happen on a day that those humans will look at their calendars and say "oh, it's [that day]! Better do [that thing]!"

The comment above was referring to the second kind, but it's true that it englobed too much

Re: UTC Is Enough for Everyone, Right?

#152

Post by saagarjha »

ris wrote: post #69

If you want a technical audience to read your page, get rid of the videos and unnecessary animations.

> It’s so predictable that developers will pooh-pooh having to write timezone code, almost as much as it is predictable that some clueless commenter on Hacker News will complain that this page has autoplaying video on it. And then someone will calmly quote this passage in response, quietly pleased with themselves that the initial commenter was rude and certainly didn’t read the post at all. Then a third person will chime in on the thread saying the author was playing you all like a fiddle anyway, and the real problem is that the post was way too long to start with.

I guess I get to play the part of the second person…

Re: UTC Is Enough for Everyone, Right?

#155

Post by senlutomchen »

Terr_ wrote: post #122
0x0 wrote: post #33

So the article seems to imply you should store all timestamps as UTC (with an additional timezone string ID). But for events in the future that needs to happen on a specific "wall clock point in time", it might be better to actually store the yyyy-mm-dd hh:mm:ss as a string with a timezone next to it, because timezones can and do change often unpredictably. If you pre-calculate what "4.00pm next August 1st" is as a U…

IMO the biggest problem isn't the how you store information or even do the date-math. The most frustrating thing is drawing out user-intent, distinguishing between two use-cases which are so similar that most users won't even know what they want. Specifically, future events which aren't tied to a geographical location, and ones which are. And in the latter case, determining which single location it should be pegged t…

Another example of confusing user-intent is "last X days".

I.e Does "Last 2 days" indicate: A. Last 48 hours? B. Yesterday + Today up to now C. Yesterday + the day before.

Re: UTC Is Enough for Everyone, Right?

#156

Post by leonroy »

0x0 wrote: post #33

So the article seems to imply you should store all timestamps as UTC (with an additional timezone string ID). But for events in the future that needs to happen on a specific "wall clock point in time", it might be better to actually store the yyyy-mm-dd hh:mm:ss as a string with a timezone next to it, because timezones can and do change often unpredictably. If you pre-calculate what "4.00pm next August 1st" is as a U…

We spent weeks on this for our new conference calling app to determine when a user says "Setup a call at 10am for my group every week" that come October 29th 2018 the call takes place at 10am, not 9am following a DST change.

After a heckuva lotta research and reading we determined that we needed to store the scheduled meeting time using two values; the local datetime and the desired timezone eg.

scheduledAt: 2018-05-29T23:41:16.167 scheduledAtZone: Europe/London

Everything else in the system like created, updated, ended data is stored using UTC and transposed on the client using the user's stored time zone preference. eg.

createdAt: 2018-05-29T22:41:16.167Z

The application server your app is running on of course needs to run on Etc/UTC but with that in place (so far...touch wood) we haven't had a problem in our usage.

Re: UTC Is Enough for Everyone, Right?

#157

Post by ATsch »

sp332 wrote: post #3
ATsch wrote: post #2

The author expected this comment, but i'd still like to note that this website saturates at least one core of my laptop, more depending where I scroll.

There are tons of autoplaying videos, and each one takes a few % of my CPU. The biggest difference for me was the one just after the heading "Who needs December 30, 2011 anyway". Turning off autoplay (e.g. media.autoplay.enabled in Firefox) fixed it. You can still play each video by right-clicking on it.

yeah, that map zoom animation eats half a core for me

Re: UTC Is Enough for Everyone, Right?

#158

Post by Animats »

cryptonector wrote: post #62
0x0 wrote: post #33

So the article seems to imply you should store all timestamps as UTC (with an additional timezone string ID). But for events in the future that needs to happen on a specific "wall clock point in time", it might be better to actually store the yyyy-mm-dd hh:mm:ss as a string with a timezone next to it, because timezones can and do change often unpredictably. If you pre-calculate what "4.00pm next August 1st" is as a U…

Yes, you have to periodically recompute times. For example, if you store time in TAI then you'll have to recompute all other future times as leap seconds are announced.

There's "Google time", their approach to leap seconds. 12 hours before a leap second, Google's version of UTC time starts running slightly slow, so that it loses a second over the next 24 hours.[1]

Some Google database systems rely on tight time synchronization to order update events, so they had to have a global monotonic clock.

[1] https://developers.google.com/time/smear

Re: UTC Is Enough for Everyone, Right?

#159

Post by cryptonector »

hanikesn wrote: post #118
cryptonector wrote: post #62

Earlier quoted context omitted.

Yes, you have to periodically recompute times. For example, if you store time in TAI then you'll have to recompute all other future times as leap seconds are announced.

I don't think I ever heard of anyone (besides scientists) to store timestamps in TAI. Though Ada supports leap second calculations in the standard library: http://www.adaic.org/resources/add_content/standards/05rat/h...

Dealing with time well into the future is rough because of the unknown timezone changes and unknown leap seconds. There's not much you can do.

Computing future times in TAI from user inputs in wall clock time is fraught, so I guess you can't store TAI in those cases.

For a calendar app, since users want to deal in wall clock time, you have to store time with timezone and with leap seconds (so UTC + time zone). And you have to store timezone, not offset to UTC -- timezones can change.

At least internally, however, dealing in TAI can be helpful[0].

Also, IIRC there's a proposal to redefine UTC as without leap seconds[1]... That scares me. Users really need wall clock time.

    The continued existence of TAI was questioned in a 2007 letter from the BIPM to the ITU-R which stated "In the case of a redefinition of UTC without leap seconds, the CCTF would consider discussing the possibility of suppressing TAI, as it would remain parallel to the continuous UTC."[16]
[0] ttps://cr.yp.to/time.html

[1] https://en.wikipedia.org/wiki/International_Atomic_Time

Re: UTC Is Enough for Everyone, Right?

#160

Post by 0x0 »

leonroy wrote: post #156
0x0 wrote: post #33

So the article seems to imply you should store all timestamps as UTC (with an additional timezone string ID). But for events in the future that needs to happen on a specific "wall clock point in time", it might be better to actually store the yyyy-mm-dd hh:mm:ss as a string with a timezone next to it, because timezones can and do change often unpredictably. If you pre-calculate what "4.00pm next August 1st" is as a U…

We spent weeks on this for our new conference calling app to determine when a user says "Setup a call at 10am for my group every week" that come October 29th 2018 the call takes place at 10am, not 9am following a DST change. After a heckuva lotta research and reading we determined that we needed to store the scheduled meeting time using two values; the local datetime and the desired timezone eg. scheduledAt: 2018-05-…

Yep, that's my conclusion too: storing timestamps for events in the past and up to present time - unix timestamp with optional tzid, and re-calculate local time formatting from scratch for display every time. Events in the future, do the opposite: store as yyyymmddhhiiss + tzid, and re-calculate utc from scratch for calculations every time. As a rule of thumb, at least.
Post reply on HN