On 25-7-2011 18:23, Jürgen Hestermann wrote: > Reinier Olislagers schrieb: ... >> If so, I'll try and get timezone description from the OS... > > Timezone information is not enough to get reliable dates. Dependend on > where dates origin from they can be wrong (wrong clock on computer, > wrong time zone on computer, file times extracted from archives not > storing time zone). Also, when calculating UTC time on a local > (computer) there is an ambiguity for times 2:00h to 3:00h when daylight > saving is invoked in spring. A time of 2:30h can be before or after > having switched back the clock but a program cannot determine which case > applies from the computer clock alone. Yep, I know, depressing... > > And even if dates are correctly stored in UTC it is not easy to reliably > get back the "local time". Daylight savings were changed in the past > (and may also change in the future). If you have a date/time of > 2001-05-01 18:00 UTC it is not easy to predict what local time it was in > time zone x. You would need a history of all daylight saving algorithms > of the past and the future for all time zones (or even countries). Agreed. > > Having time zones added (or storing it in UTC) is better than not doing > this but it's still far away from being "correct". Fortunately Ludo Brands showed me that storing timezone info in the XML file I was exporting (for ADO.Net) was not necessary.
I just tested it as well... I suppose it's best left to the user to interpret what a date/time means exactly, just as he will have to do with currency fields without any currency indicator... However, what I can do is add an XML comment indicating what offset/timezone the computer is currently using. This may help interpretation... Thanks for the detailed explanation, Reinier _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
