For the data collection systems we use we store only UTC in the database. The application can translate times to the appropriate time zone and format for the user as required. This variable complexity needs to be controlled into one layer of your program. Since governments, even some city ones, have the authority to change the time zone or implementation date for their population, there is a high potential for change. 3rd party time zone rule libraries can externalize most of the maintenance work without affecting the core app or the database.
regards, Adam DeVita On Wed, Jan 14, 2015 at 12:57 PM, Simon Slavin <slav...@bigfraud.org> wrote: > > On 14 Jan 2015, at 5:53pm, Nigel Verity <nigelver...@hotmail.com> wrote: > > > I generally just use a fixed-length 14-character string to store the > date and time in YYYYMMDDHHMMSS format. It accommodates any time stamp > across a 10,000 year timespan and also supports simple date/time > comparisons and sorting. > > There is no problem with using that format. However I would advise you to > make a note in your documentation, and/or to add comments to your code, > saying what TimeZone these stamps are in. > > Simon. > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- -------------- VerifEye Technologies Inc. 151 Whitehall Dr. Unit 2 Markham, ON L3R 9T1 _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
