On Tuesday, 29 July, 2014 20:31 Will Fong <w...@digitaldev.com> said:
>On Wed, Jul 30, 2014 at 10:01 AM, Keith Medcalf <kmedc...@dessus.com>
>wrote:
>> Store and retrieve everything in the database in Zulu time. Whether
>this means using timestrings, UNIX timestamps, JD or MJD floats is up to
>you. The application (user interface) is responsible for converting
>retrieved data to the "display timezone" on output and convert data from
>the "input timezone" on input.
>> This is the only reliable way to handle multiple timezones. There are
>lots of moronic ways and five-nines (asctually more like nine-nines) of
>all software written use those moronic methods and for that reason do not
>work properly ("not work properly" being defined as anything somewhere
>between producing incorrect or ludicrously entertaining results and just
>puking all over the floor). In many cases "not working" but "not puking"
>is acceptable provided that the moronic behaviour is internally
>consistent. In others, "not working" is fatal.
>Well, PostgreSQL's method for this to be handled at the
>client/connection level seemed to have worked very well, and doesn't
>seem very "moronic". Having this handled at the database level makes
>the application(s) much less prone to bugs.
PostgreSQL's methods seem well designed (according to the current
documentation). It uses a reasonable timezone database (Olsen), allows you to
specify the "presentation" timezone (the timezone from which timestamps are
converted on input and to which timestamps are converted on output), stores
only GMT/UTC, and performs all conversions on "initial" input/"final" output,
while working entirely in GMT/UTC internally.
In other words, it does exactly what I said needs to be done at the
presentation layer within the SQL input/output parser routines.
Many products are far more brain-dead.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
