71–80 of 321 posts
Typo note to author: therefor should be therefore.
I also don’t understand why modern English doesn’t take advantage of them like modern German does.
I recently ran into a completely novel time bug while working with Excel file for GoodGrids. In Excel files, date and time values are stored as epoch time. But you can not tell what time a particular number represents until you check whether the file was made with Excel on Windows or on the Mac. It turns out, the developers chose a different start of the epoch on these two platforms.
A while ago I came to the conclusion that time is simple from any one perspective, but complicated when you try to handle all possible perspective. Try to explain the complexities of time to someone who does not travel, resides in the same timezone all of their life, and does not need to coordinate with anyone outside of their timezone. For them, the rules that govern time are pretty easy.
Birthdays (as the article mentioned) are not points in time and mean different things depending on where you are, so best stored as a year-month-day combo without any zone information.
Past times are not that big of an issue actually, just use UTC and convert to local time to display, but calendars schedule for the future, and you can't always calculate a future time in UTC.
In e.g. distributed system where monotony and ordering is important UT1 would actually be even better than UTC, as UTC has occasional jumps (hence the workarounds, like googles skewed NTP)
> 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…
The Unix Epoch does not handle leap seconds (time just rewinds). Google's time smearing approach is a great hack, but trades one issue for another.
This is a niche case in high resolution time, auditing and security considerations.
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
Right? And that that 37 second offset will change from year to year? I was waiting for the bombshell, that some minutes actually have 61 seconds in them, and some have 59 seconds (though it occurs to me that I don't know if astronomers ever add or subtract more than a second for any given clock adjustment).
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…
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 account the time zone as you may need to deal with daylight saving time.
However “next Tuesday” is not a date-time, but a relative difference from where you are now and by pre-calculating you lose information.
Also relevant, in such cases storing the time zone doesn’t help because the user himself might travel and next Tuesday at 7:00 can remain the same, no matter what time zone you’re talking about.
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…
For the case you propose, I read it as a "meeting" planned at a point in the future. In this case storing the start of the meeting as a bare timestamp is inappropriate design. What really should be encoded is the set of rules for identifying the proper timestamp. There was an existing standard mentioned for that which I'd use as a starting point if designing or implementing (if I chose their design) such a system.