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

251–260 of 321 posts

Re: UTC Is Enough for Everyone, Right?

#251

Post by erpellan »

jeremyevans wrote: post #52
da_chicken wrote: post #47

> Properly storing timezone-aware times I'd just like to point out that a lot of RDBMSs support storing date and time alongside timezone information directly without using two separate fields. SQL Server has datetimeoffset, PostgreSQL has timestamp with time zone, and Oracle has timestamp with time zone. I think MySQL does as well, but I seem to recall something strange about it. Or maybe that's just me expecting MyS…

> I'd just like to point out that a lot of RDBMSs support storing date and time alongside timezone information directly without using two separate fields. SQL Server has datetimeoffset, PostgreSQL has timestamp with time zone, and Oracle has timestamp with time zone. PostgreSQL's "timestamp with time zone" doesn't store timezone, it converts the time to UTC and stores that, and on retrieval converts the value to the…

Part of the problem is the ANSI SQL standard specifies that 'TIMESTAMP' does not have any offset/timezone applied. The postgres docs pretty much admit this is a bad idea and recommend all timestamps be stored as 'TIMESTAMPTZ' (aka TIMESTAMP WITH TIME ZONE).

It's problematic when moving data between systems with different Locale settings. Because ANSI timestamps are stored as 'local' time, timestamps will shift if you read from a DB in New York and write to one in San Francisco. Both will interpret an ANSI SQL timestamp as being in their locale unless told otherwise.

Re: UTC Is Enough for Everyone, Right?

#252

Post by bcaa7f3a8bbc »

jandrese wrote: post #111
welterde wrote: post #76

Earlier quoted context omitted.

The goal is to always keep UTC within one second of UT1. Short of very drastic events I don't think it will ever be neccessary to introduce more than one leapseconds in a fairly long time interval. And even if it was, I would think that they would do seperate leapseconds events some time apart.

There are two official primary times a Leap Second can occur. December 31 and June 30. There are provisions for more slots, but they're not really expected to ever be used. Like most things associated with time Leap Seconds are a huge headache to implement properly on computers. If you want some fun watch what various NTP servers around the world do when Leap Seconds roll around. You will see clocks that start to dri…

> If you want some fun watch what various NTP servers around the world do when Leap Seconds roll around. You will see clocks that start to drift for 15 minutes before jumping to the right time, some that wait until 8AM local time on the following day to correct, and some that just go crazy. And of course you have Google's clock smearing across most of a day.

As a note, clock smearing is a non-standard hack invented by Google, because most programs are too broken to handle the leap second warning event and inserting/deleting a second properly, per designed. And you shall never add a clock smearing server to the www.pool.ntp.org.

Re: UTC Is Enough for Everyone, Right?

#253

Post by TorKlingberg »

marshray wrote: post #162

There are only two types of time systems: 1. TAI, and systems that have a fixed 1-to-1 mapping to it (e.g., GPS). 2. Systems that are generally unable to calculate how many seconds will elapse until your next birthday. UTC is in this category. Articles like this spend a lot of time on the varying degrees of insanity in category 2. But I would rather start with category 1 and negotiate any additional complexity from t…

The exact start of my birthday depends on where will be at the time. It starts and ends at midnight in the current timezone. With some clever time zone jumping my birthday could start twice or more in the same year. Also if I was born on February 29, you need to move it Feb 28 or March 1 on non-leap years.

Re: UTC Is Enough for Everyone, Right?

#254

Post by [deleted] »

tialaramex wrote: post #178
cryptonector wrote: post #159

Earlier quoted context omitted.

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

"That scares me. Users really need wall clock time." Why would getting rid of leap seconds from UTC be a problem for that? The reason there are leap seconds is nothing to do with wall clock time, it's because some people feel the time ought to be intimately connected to the Earth's rotation, but the Earth doesn't oblige by rotating steadily. In my view the people demanding this relationship be maintained ought to tak…

[deleted]

Re: UTC Is Enough for Everyone, Right?

#255

Post by mseebach »

daveFNbuck wrote: post #207
matt-tingen wrote: post #172

Earlier quoted context omitted.

Even something as simple as "tomorrow" can be ambiguous. I often ask my phone to set a reminder for tomorrow. If I'm asking after midnight, what I really mean is "today" since I haven't gone to sleep yet. Google seems to get this right, thankfully.

> Google seems to get this right, thankfully. Gets it right for you. If I mean today, I say today. This is especially true when I'm talking to a computer.

Both the words "today" and "tomorrow" ("morrow" being related to the word "morning") are defined in terms of the day, not whether it's before or after midnight. "Noon tomorrow" spoken at 23:55 or 0:05 refers to the same point in time (~12 hours later) in human language. I would argue that "today" is basically unassigned at night - there is no current day in scope.

Sometimes we need to use non-human language to communicate intent correctly to a computer, but we shouldn't let that redefine perfectly good and well established human language.

Re: UTC Is Enough for Everyone, Right?

#257

Post by chaz6 »

This article covers a lot of important points, but I must nitpick one in particular. GMT is not a timezone. Europe/London is a timezone. GMT is solar time which is distinct from UTC as a time system. The purpose of leap seconds is to track the difference between TAI and GMT which results in UTC (i.e. UTC = TAI + leap seconds).

Since everything is relative, my preference for recording accurate historical time is microseconds since TAI0. Everything else prior and future is an estimate.

Re: UTC Is Enough for Everyone, Right?

#258

Post by tjoff »

matt-tingen wrote: post #172
senlutomchen wrote: post #155

Earlier quoted context omitted.

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.

Even something as simple as "tomorrow" can be ambiguous. I often ask my phone to set a reminder for tomorrow. If I'm asking after midnight, what I really mean is "today" since I haven't gone to sleep yet. Google seems to get this right, thankfully.

Google also says that an event that took place 47 hours ago is "yesterday" which is hilariously bad.

Just print the date and time.

Re: UTC Is Enough for Everyone, Right?

#259

Post by gmac »

Asooka wrote: post #250
matt-tingen wrote: post #172

Earlier quoted context omitted.

Even something as simple as "tomorrow" can be ambiguous. I often ask my phone to set a reminder for tomorrow. If I'm asking after midnight, what I really mean is "today" since I haven't gone to sleep yet. Google seems to get this right, thankfully.

Tomorrow is tied to the morrow, so it isn't tomorrow until sunrise.

Seems like the only correct behaviour, really, would be to ask the user for clarification.

Re: UTC Is Enough for Everyone, Right?

#260

Post by acqq »

simonh wrote: post #242
acqq wrote: post #229

Earlier quoted context omitted.

Why would anybody schedule events in local time to happen on leap seconds?

If it's say a scheduler for an application, you might have an activity that occurs every x seconds. At a previous job events like that were often scheduled such that x was a different prime number for each task, in order to minimize regular simultaneous executions. A system like that could easily end up with tasks running on a leap-second.

Your example isn’t scheduling in local time but in system time.

In local time would be “my meeting starts at xxx”. Leap seconds schould not be involved there, and neither the system time. The users aren’t going to be glad you’re doing that.

Post reply on HN