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

181–190 of 321 posts

Re: UTC Is Enough for Everyone, Right?

#181

Post by tlrobinson »

> (My all-time fave is RFC 2606, thanks for asking! I’m in awe of that absolute unit. Where would we be without that banger? We’d be in complete fucking chaos, that’s where.)

RFC 2606 ("Reserved Top Level DNS Names") not RFC 2616 ("Hypertext Transfer Protocol -- HTTP/1.1")? I would have gone with the latter.

Related: I just noticed Cloudflare's DNS service (1.1.1.1) follows the suggestion in RFC 2606 and resolves *.localhost to 127.0.0.1. That can be handy for local web development etc. There are some other wildcard domains that resolve to 127.0.01 but I usually can't remember them.

Re: UTC Is Enough for Everyone, Right?

#182

Post by _asummers »

dpark wrote: 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…

I might not be remembering my History of Math correctly, but my recollection is that the Babylonians used Base 60, and 12 is an even subdivision of that. I also recall other Asian number systems having base 12 in some capacity, so there may be something to the counting methodology he outlined if it showed up in a few separate parts of the world.

Counting that way on one hand and then using the other hand to tally the groups would give you 5 sets of 12 or 60.

Re: UTC Is Enough for Everyone, Right?

#183

Post by stouset »

mikekchar wrote: post #179
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…

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.

Re: UTC Is Enough for Everyone, Right?

#184

Post by meta_AU »

tlrobinson wrote: post #181

> (My all-time fave is RFC 2606, thanks for asking! I’m in awe of that absolute unit. Where would we be without that banger? We’d be in complete fucking chaos, that’s where.) RFC 2606 ("Reserved Top Level DNS Names") not RFC 2616 ("Hypertext Transfer Protocol -- HTTP/1.1")? I would have gone with the latter. Related: I just noticed Cloudflare's DNS service (1.1.1.1) follows the suggestion in RFC 2606 and resolves *.l…

xip.io is one service that will wildcard for any IP address.

Re: UTC Is Enough for Everyone, Right?

#185

Post by [deleted] »

gsich wrote: post #171
XR0CSWV3h3kZWg wrote: post #141

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.

[deleted]

Re: UTC Is Enough for Everyone, Right?

#186

Post by jobigoud »

erpellan wrote: post #132

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.

Re: UTC Is Enough for Everyone, Right?

#187

Post by InclinedPlane »

Lemme tell you about a fun little bug in the TFS Build system. You can create build definitions, you can set the schedule for those builds. You can, for example, schedule builds that run at a certain time of day every day (or every weekday or every Tuesday, or whatever). That build information is then stored in an internal representation which is actually used for scheduling. And that internal representation, it uses UTC times. Can you see the bug here already?

So, your build system will be scheduling daily builds at the same time every day, and then suddenly after a DST change those builds will be an hour off from when you expect them. But here's the even more fun part. If you simply happen to edit and then save one build definition after the DST switch then it'll be saved with a different UTC time (due to the different UTC offset) and it'll run at the correct local time of day.

Re: UTC Is Enough for Everyone, Right?

#188

Post by jobigoud »

gsich wrote: post #171
XR0CSWV3h3kZWg wrote: post #141

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.

Your integer is wrong because it was computed by translating from the current offset of the timezone. What we are saying is that the timezone definition might change in the future (ex. Government no longer honor DST). At that point when you translate back your timestamp into local time it no longer matches the original schedule that the user set.

Re: UTC Is Enough for Everyone, Right?

#189

Post by Iv »

Jedd wrote: post #177
dpark wrote: 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.

> dozeine.

French nitpicker here. We now write it "douzaine" but spellings have changed through the ages.

Re: UTC Is Enough for Everyone, Right?

#190

Post by Iv »

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…

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

Post reply on HN