Live data from Hacker News

UTC Is Enough for Everyone, Right?

zachholman.com

171–180 of 321 posts

Re: UTC Is Enough for Everyone, Right?

#171
post #138

Earlier quoted context omitted.

There is a solution for this, Unix timestamps.

That fails for the case that you have an appointment at 3pm in 30 days, and 15 days later the timezone's offset changed.

How does that fail? I have an integer for an appointment. I am at that appointment at that given integer. This applies for all timezones. If the timezone changes, the integer does not. What you are saying is that the timezone changes and the integer changes aswell, but then it's not the same appointment anymore.

Re: UTC Is Enough for Everyone, Right?

#172
post #122

Earlier quoted context omitted.

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.

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.

Re: UTC Is Enough for Everyone, Right?

#173
post #171

Earlier quoted context omitted.

That fails for the case that you have an appointment at 3pm in 30 days, and 15 days later the timezone's offset changed.

How does that fail? I have an integer for an appointment. I am at that appointment at that given integer. This applies for all timezones. If the timezone changes, the integer does not. What you are saying is that the timezone changes and the integer changes aswell, but then it's not the same appointment anymore.

From the user's perspective it is the same appointment. They think they have an appointment at 3:00 PM on Thursday. If there's a timezone change, and you just stored an integer, then from the user's perspective the meeting changed from 3:00 PM to 2:00 PM.

Of course, if you have a meeting that spans timezones, this is unavoidable. I think the real solution actually lies in how the meeting time is expressed to the user so they don't have misconceptions about it.

Re: UTC Is Enough for Everyone, Right?

#175
> If you're like me and immediately said ohhhhhhhhhhhh, so THAT'S why there's twelve hours in a day! and immediately followed it up with: wait, why the fuck are they using twelve instead of ten? ...

> It's most likely because you have twelve joints in your hands: three in each of the four fingers, excluding the thumb. I thought that was pretty nifty to discover. Like, I had never looked at my hands before, really. Hands are really wild, when you think about it.

Probably not. This explanation of duodecimal is really farfetched and I’m pretty sure it arose from someone staring at their hands desperately trying to come up with a way to count 12 on their fingers to explain this. (Ten fingers and two feet seems as likely.)

Clocks are (probably) divided into (two sets of) 12 hours for the same reason feet are divided into 12 inches. Because it’s convenient for everyday use. Subdivisions of 1/12th suck for complex math (if your number system is decimal anyway), but are great for lay use. 12 subunits captures halves, thirds, and quarters, all of which are very intuitive and very common in everyday use.

12ths are handy enough that we have a special word for “12 of something” (dozen) even though our numbering system is decimal.

Re: UTC Is Enough for Everyone, Right?

#176
post #80

That was an efficient way to heat a battery.

Same here. About a quarter way through the article I figured out what the hell my system was running; then, halfway through, I had enough. I disabled Javascript and reloaded the page. No dice. Page renders perfectly including videos. I scrolled a little faster and skipped parts from there on.

Re: UTC Is Enough for Everyone, Right?

#177
post #175

> If you're like me and immediately said ohhhhhhhhhhhh, so THAT'S why there's twelve hours in a day! and immediately followed it up with: wait, why the fuck are they using twelve instead of ten? ... > It's most likely because you have twelve joints in your hands: three in each of the four fingers, excluding the thumb. I thought that was pretty nifty to discover. Like, I had never looked at my hands before, really. Ha…

> 12ths are handy enough that we have a special word for “12 of something” (dozen) even though our numbering system is decimal.

My understanding is that the etymology of dozen is originally traced back to duodecim (Latin for twelve) via French dozeine. Which is interesting, but doesn't really explain why it's special beyond your observation that it's a highly composite, but comfortably small, number.

Re: UTC Is Enough for Everyone, Right?

#178

Earlier quoted context omitted.

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 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 take responsibility for fixing it from their side. Speed up or slow down the Earth. Can't? Too bad then, but don't expect us to keep fiddling with the clocks.

Re: UTC Is Enough for Everyone, Right?

#179
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…

When we were building a golf tee time web site we eventually decided on this as well: always store the date-time as a string in the timezone local to the event. Convert to a date-time object in whatever timezone the user prefers (or golf tee time service APIs prefer :-P) on demand.

There is still a caveat, though. Locations can change timezone. Sometimes they do it fairly often (like every few years). You need access to a good timezone/location database that is updated regularly :-(

When we were doing this project, I was really surprised at how often we got problems. If you sell things all over the world (there are golf courses in ridiculous places), the probability that you will stumble into an anomaly is surprisingly high. Alas, this project was not a commercial success as the margins on tee times are quite small (and the tee time services you have to work with are often quite badly written). But it was quite fun to work on.

Re: UTC Is Enough for Everyone, Right?

#180
> [1883] ... a bunch of rich, white railroad tycoons met at a fancy Chicago hotel to agree on a standard timezone so their trains would work better together...

The Brits did this for their railroad in 1847. Time balls were used to synchronise clocks before telegraph and radio.

https://en.wikipedia.org/wiki/Time_ball

On clock accuracy, I was reading last night about time dilation due to gravity, and the difference in time rates from points less than one meter apart in height on earth have been experimentally verified.

Post reply on HN