81–90 of 321 posts
OK, I guess this is a joke, but this actually began to happen during the Industrial Revolution, when factory owners were obliged, as part of worker training, to teach workers how to read a clock.
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.
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…
Actually the meaning of a date like: 2018-05-26T13:45:21+02:00 Will never change, regardless how many time zone changes you may have. What does change is the method to compute the time difference. So can you say how many days, hours, minutes, seconds ago that was from: 2043-02-12T11:15:16+02:00 You won’t be able to, because then you have to account for leap seconds, etc. Also “next Tuesday” does have to take into acc…
> 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…
Times don't have timezones - places have timezones. The idea that time handling is made easier by attaching timezones to times is the cause of so many headaches. Correct time handling involves understanding place - the place where things happen, the place where the user is observing them from, the place where a clock displays a particular time.
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…
Actually the meaning of a date like: 2018-05-26T13:45:21+02:00 Will never change, regardless how many time zone changes you may have. What does change is the method to compute the time difference. So can you say how many days, hours, minutes, seconds ago that was from: 2043-02-12T11:15:16+02:00 You won’t be able to, because then you have to account for leap seconds, etc. Also “next Tuesday” does have to take into acc…
Sadly I didn't have enough time to read the whole article... But I wish we could all just use one time. For some, midday would be 12, and for others it might be 19, but we already all use the same dates regardless of whether February is winter for one location or summer for another.
Also that system will probably devolve into defacto timezones without actual definitions where business in nearby areas decide on what constitutes reasonable hours based on businesses around them and the relative solar time but instead of reasonably crisp boundaries like you have today defined on a map it'll be a slow bleed and interspersing between multiple sets of '9-5' hours.
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…
Not the only reason I use a credit union these days.
It is truly nightmarish stuff. I am convinced you could run a very profitable consultancy specializing in debugging date and time related problems in people's systems.
Earlier quoted context omitted.
We don't need more standards. We have UTC and TAI. Pick one, use that one.
Leap smearing isn't related to TAI, it's just a way to minimize the effect of leap seconds on machines using NTP servers.
> 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…
Erp. This sentence made me wince. Times don't have timezones - places have timezones. The idea that time handling is made easier by attaching timezones to times is the cause of so many headaches. Correct time handling involves understanding place - the place where things happen, the place where the user is observing them from, the place where a clock displays a particular time.