On 7/25/2011 15:53, José Mejuto wrote:
Hello FPC-Pascal,
Monday, July 25, 2011, 6:23:21 PM, you wrote:
JH> And even if dates are correctly stored in UTC it is not easy to reliably
JH> get back the "local time". Daylight savings were changed in the past
JH> (and may also change in the future). If you have a date/time of
JH> 2001-05-01 18:00 UTC it is not easy to predict what local time it was in
JH> time zone x. You would need a history of all daylight saving algorithms
JH> of the past and the future for all time zones (or even countries).
This already exists, but future settings are impossible to predict, so
a local time in the future is a no-no and should be avoided as much as
possible.
while i agree, i feel that it is also important to point out that one may easily
perform future date calculations based on several different formulas with the
understanding that they may not be accurate when that date arrives if the
formula changes for some reason... the recent examples given are the US daylight
saving time changes (note: NOT daylight savings [specifically note there is NO
's' on "daylightsaving"]) but it is easy enough to work with this... i've done
it for years with TP3 and TP6 code... easier in recent years but still... i've
formulas from somewhere that convert between numerous calendars... i believe i
even have one for the myan calendar but like most of what i have, it is all
older TP3-6 code and it is also a matter if me finding it in my library :?
for general purposes, storing in local time is OK but it really needs to include
the timezone info for the local time or it needs to be converted to UTC so that
multi-timezone apps can properly correlate the actual events on a uniform
timeline... this can be a very critical point in some applications... PoS apps,
being one... database transactions being another one...
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
