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

51–60 of 321 posts

Re: UTC Is Enough for Everyone, Right?

#51

Post by cryptonector »

oconnor663 wrote: post #23
setquk wrote: 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…

If two spacecraft start going fast enough in different directions, they can disagree about what order two different events happened in. At that point, it's not enough to give an event a single time coordinate in some reference frame; you also need to know its position in space.

If you can compute time dilation, then you can map back to Earth time (UTC) or whatever, and use that in your communications. Otherwise you give up and use only local time in your communications. And if ever our interpid travelers meet again they can compare their clocks and determine dilation (which will not change the fact that they'll have observed events in different orders, but they'll understand this, hopefully).

Re: UTC Is Enough for Everyone, Right?

#52

Post by jeremyevans »

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 connection's time zone.

Re: UTC Is Enough for Everyone, Right?

#53

Post by cryptonector »

welder wrote: post #48
pquerna wrote: post #29

Love this article, but one thing it skipped on was more in-depth on Leap Seconds. You see, UTC, is kinda like another human-made-up timezone. Humans made up some rules, and UTC is a 37 second offset from TAI / International Atomic Time: https://en.wikipedia.org/wiki/International_Atomic_Time

https://developers.google.com/time/smear

We don't need more standards. We have UTC and TAI. Pick one, use that one.

Re: UTC Is Enough for Everyone, Right?

#54

Post by 314 »

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.

But it does look gorgeous and it absolutely screams luxury layout and typesetting... so there’s that.

Re: UTC Is Enough for Everyone, Right?

#55

Post by draw_down »

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…

Sure... except, what is "future"? Or rather, how do we know which things are in the future?

Re: UTC Is Enough for Everyone, Right?

#56

Post by cryptonector »

batbomb wrote: post #43
pquerna wrote: post #29

Love this article, but one thing it skipped on was more in-depth on Leap Seconds. You see, UTC, is kinda like another human-made-up timezone. Humans made up some rules, and UTC is a 37 second offset from TAI / International Atomic Time: https://en.wikipedia.org/wiki/International_Atomic_Time

Really, it's TAI that should be enough for everyone.

Yes. Just count seconds and have a handy database of timezones and another of leap seconds. Yes, your computations of future times will be wrong if you can't predict leap seconds accurately (indeed, you cannot!). But if we're talking about a calendar then you want to store wall-clock times and every so often recompute a near-in-the-future time at which to resolve (into TAI) all relevant near-in-the-future times in the calendar so you can fire off reminders/alerts/whatever at the right times.

Re: UTC Is Enough for Everyone, Right?

#57

Post by vikasg »

blunte wrote: post #37
vikasg wrote: post #32

Earlier quoted context omitted.

Software is built for humans to use in the real world. While reshaping the entire world might make the code simpler, it's not a practical solution.

Indeed it simplifies software, but it also makes life much easier for humans trying to coordinate communication across timezones. There's probably some research somewhere estimating the cost to business (or loss of revenue) from mistakes in doing timezone conversions. In the simplest case, if you have a business call with someone halfway around the world, and one of you has recently gone into or out of daylight savin…

No one is disputing that a better system cannot be devised. This is true for many problems in the world. If you could start from the zero state, you can do it much better.

So let me say this: _coming up with the ideal system is not hard_. But how will you transition the world from its current state to this ideal state? Consider that the metric system (or SI), which is much better than the US system of measures, has still not been adopted in the US. Why? Because the problem of transitioning between systems is called politics.

Re: UTC Is Enough for Everyone, Right?

#58

Post by cryptonector »

314 wrote: post #54
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.

But it does look gorgeous and it absolutely screams luxury layout and typesetting... so there’s that.

Huh, I guess I need to enable more scripts.

Re: UTC Is Enough for Everyone, Right?

#59

Post by coldacid »

hinkley wrote: post #46

I have been thinking a lot lately that we are trying to solve class of XY Problem. Universal time is in part about trying to order events in a strict order. Probelm is, nobody observed that order. Later we infer things about the system based on this chronology but it’s completely fictitious and we have to stretch our brains to explain the state of the system. The Java Memory Model, and subsequently several other lang…

If people could regularly reason like that, asynchronous programming wouldn't be such a pain in the ass.

Re: UTC Is Enough for Everyone, Right?

#60

Post by ssijak »

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…

That sounds dumb (if column type is called like that text in the quotes)
Post reply on HN