On Sun, Dec 13, 2015 at 6:44 PM, Keith Medcalf <kmedcalf at dessus.com> wrote:
> We have been doing daylight savings changes to and from twice a year for > as long as I remember (that is more than 100 times) and we still cannot > manage to do it properly. Leap years have been occurring for a long time > and somehow we still manage to get that wrong too. Multiple timezones have > existed for a long time and we cannot get that right either. In > combination with Daylight Savings Rules, Timezones, and the want of > Politicians to fiddle with daylight savings time completely arbitrarily, > the situation is indeed grim. > As to whether they could be incorporated into SQLite, that is > interesting. Overall the manipulations are rather simple -- the problem is > the database of tz data (the IANA aka Olsen database). Of course, the data > could be stored in the database itself, but this raises the issue of having > UDFs access the database. I suppose it would not be too difficult (or too > large) to load the entire database at extension load time -- the entire > IANA database of all known timezone/transition information is just slightly > larger than 512KB... > Not a horrible size for a modern desktop operating system, but certainly not something you would want to foist onto smaller embedded systems. Speaking of which, that reminds me of something I once heard: > > "On hearing the explanation of Daylight Savings Time, the old Indian Chief > said with a shake of the head: "Only a white man could believe that > cutting a foot off the bottom of a blanket and sewing it on the top would > make the blanket any longer..."" > Amusing, though of course the intent is not make the day longer, just to save the daylight in the early morning and use it in the evening. It's a sliding window algorithm. :) I'm just glad I didn't live in the "wild west" of DST. Since 1966 DST has been pretty stable. A couple 'permanent' changes and some short term changes at specific times. Prior to 1966, individual states and localities were free to do whatever the heck they wanted, and it was confusing. I haven't looked at the IANA database in depth, but I did download it so that I could take a glance. It does include a lot of information, but it'll never be complete. Complete enough for the needs of most people, of course, who just care about adjusting UTC to legal local time for a general area, but there are places (like West Wendover, NV) that have been effectively on in the mountain time zone while legally in the pacific time zone (until they were legally moved to mountain time in 1999). If you depend on the timezone database it looks like you'll always get the "observed" time for West Wendover, but if you want the legal time, there is no rule for that. Note: I am not advocating yet more changes to the time database, especially for such a little quirk. Just observing that if they have the most complete time database (which even includes many state & locality specific rules for the US during periods that the US didn't enforce an official start and end date) but don't have everything, then it's likely impossible to ever be 100% accurate (or rather to get everyone to agree on what 100% accurate really means). We need a metric calendar. I propose redefining the second so that a day is 100,000 seconds long... ;) -- Scott Robison
