Live data from Hacker News

UTC Is Enough for Everyone, Right?

zachholman.com

191–200 of 321 posts

Re: UTC Is Enough for Everyone, Right?

#191

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.

IIRC Google uses 4am as the cuttoff. So saying "tomorrow" after that cuttoff will be the following calendar day.

Re: UTC Is Enough for Everyone, Right?

#192

Postgres have done a really good job here. It not only understands offsets (which most devs think are timezones) it also understands timezones. What's the difference? GMT-8 is an offset. America/New_York is a timezone. This becomes important when you want to schedule a meeting on the east coast of the USA in April - Europe and the US change DST on different dates. But if you tell postgres you want a time in a particu…

What's the point of unqualified offsets like that anyway? You either use UTC or a local time in the appropriate tz.

They are useful for when you want the semantics of UTC but still a human readable time. One example is logs that people will actually read. People have a hard time doing mental math but 14:00-05:00 is just as valid as 19:00+00:00 and easier for people in Eastern Time.

It's also useful for disambiguating a local time:

2018-11-04T01:45-05:00 America/New_York 2018-11-04T01:45-04:00 America/New_York

That said, I do think they are mostly around for less noble reasons: they are way easier to serialize than actual time zone rules.

Re: UTC Is Enough for Everyone, Right?

#193

Earlier quoted context omitted.

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…

So to be absolutely correct, you store future timestamps in localtime, along with GPS coordinates of the location for the event. Then you determine the time zone of the physical locale based on a GIS lookup. Then when rendering, you offset that against the timezone of the user’s current location. I think. I hate time.

Yep. That's exactly what we did :-) For the short time we were running the service (about a year or so) it worked great ;-)

Re: UTC Is Enough for Everyone, Right?

#195
post #190
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…

> "wall clock point in time" The tricky thing to realize is that this is not a datetime. This is more of a contract/condition saying "when localtime will be at this value" or better yet "when localtime will have exceeded this value for the first time" because you know someone will put a date on a leap second or missing DST hour at one point.

All of calendaring is essentially conditions, though. Your point about this being a separate concept still stands.

It's unfortunate how few libraries exist to handle abstract datetime constructs, and how frequently programming environments screw this up. The only one I know of that doesn't mince concepts is Java 8 Time [1], where points-on-timeline timestamps are clearly separate from human-centric calendrical concepts like Time-of-Day (LocalTime) and Month-Day without a year, so there's an appropriate datatype to model lots of common use-cases of date math.

[1] https://docs.oracle.com/javase/8/docs/api/java/time/package-...

Re: UTC Is Enough for Everyone, Right?

#196
post #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.

It's special because we don't have a word for, e.g., "13 of something", say, "trezen".

Re: UTC Is Enough for Everyone, Right?

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

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

You are mistaken. Finger counting by using your thumb against one of the 12 segments of your fingers is common in many asian cultures. It's utterly simple and immensely practical as it allows you to count up to 144 with both hands.

Re: UTC Is Enough for Everyone, Right?

#198
post #5

Slightly off topic but I wonder how you handle time where dilation is present. For example if a spacecraft travels to mars and there is mars local time, plus time dilation from the journey, when does a transmission start from a reference frame? Not UTC related for sure! Or is it? And then what happens if someone else goes there in a different orbital pattern and the dilation is different. and then there is the questi…

Speaking of physics, I just read The Order of Time by Carlo Rovelli. The book is about time in physics and the title refers to the fact that is no real ordering of events.

Good read.

Re: UTC Is Enough for Everyone, Right?

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

Yes! 12-column UI layout templates caught on in the early days of RWD for good reason.

Re: UTC Is Enough for Everyone, Right?

#200
post #177

Earlier quoted context omitted.

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

It's special because we don't have a word for, e.g., "13 of something", say, "trezen".

"baker's dozen"
Post reply on HN