On Friday, 25 August, 2017 10:46, Jens Alfke <j...@mooseyard.com> said:
>> On Aug 24, 2017, at 6:28 PM, Keith Medcalf <kmedc...@dessus.com> wrote: >> Timezone is something that is applied and removed at the User >Interface level and should never exist below the presentation level. >There are cases where the timezone needs to be preserved in the data >model because it can be important to know the local time >corresponding to the event. Which "localtime"? The "localtime" according to Schroedingers' Cat or the "localtime" of the observer? Or the "localtime" at which the cat-boxer put the cat in the box -- and is that by the reckoning of the cat or the observer or the boxer? The fact of the matter is that the even occurred in "instant time" which only has a single scale (well, not really, there are several, but we assume that we are talking only about UT1 here and not Tau or other timescales), and the "timezone"/"localtime" only causes all sorts of stupidity to ensue. Events should always be recorded in UT1 instant time. That way, the time of the cat-boxing event occurs AT THE SAME TIME to everyone involved. >A common example is email: the Date header includes a timezone, so >that the recipient can tell what the local time was. For instance, >it can be significant to know whether it was 2PM or 2AM local time >when a co-worker sent you a grumpy email about a bug. >(The same goes for other communications like blog posts and chat messages.) While this may be nice, almost all clients display such times after conversion to the recipients localized time and you can only see the "originating" UT1 offset (not the timezone) by looking at the not-readily-available-to-view headers. Most things go to fantastic lengths to obscure the origin instant time offset. And the format does NOT include a timezone. It is an "instant time" often expressed as a datetime and an offset from UT1. It is, in fact, a datetime expressed as an UT1 instant. I am in Calgary, my mailserver is in Newark. However, the Localization rules for the server in Newark are set to "Canada/Mountain". However, both of us have NTP synchronization to within a few microseconds of UT1. The Ontario IESO is located in "Canada/Eastern" however they record all timestamps on their data historization in UT1 and all externally visible "instant times" are expressed with a fixed -5:00 offset. The company I work for exists all over the planet but the main datacenter is in Houston. Whenever a datetime is mentioned anywhere you have no idea what it means and is assumed to be accurate give or take 24 hours in either direction. It is even more annoying when you get crap from people who ought to know better and they say something like "August 15th at 2:00" and you have to send them back a request to specify please is that AM/PM, what year, and what is the offset from UT1 so that I know when that is. This is why ISO8601 format was invented and why it should be used. The "instant time offset" from UT1 (which is not the timezone) should only ever be excluded if the datetime expressed is already in UT1. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
