131–140 of 321 posts
Earlier quoted context omitted.
You think time has some weird edge cases, but then you get into a discussion about cultural appropriation and you realize how lucky you are to only be worrying about calendars.
I used the word "appropriating" but I wasn't talking about cultural appropriation.
I must admit to failing to see the distinction between appropriating culture and cultural appropriation.
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 particular zone it will do the calculation correctly. If you use an offset you might turn up an hour late.
This is tougher to get then time in general relativity...
$ cal 9 1752
September 1752
Su Mo Tu We Th Fr Sa
1 2 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
In my 20 years of working with software and distributed architectures, no problems have been harder than working with time zones and calendars. 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.
> 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.
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…
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.
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…
There is a solution for this, Unix timestamps.
The absolute point in time relied on future knowledge that did not yet exist, that invalidated any previous estimate of when it would occur. An external timezone reference (the Olsen DB) must be continually updated and separately referenced