Sven Barth schrieb:
Am 03.11.2011 02:39, schrieb Hans-Peter Diettrich:
IMO we have to face a problem very similar to Ansi/UTF-8/16: A TDateTime
variable can contain local time in a number of timezones (Ansi), or UTC
values (UTF), which must be interpreted accordingly, e.g. in
DateTimeToStr().
When Delphi compatible Now() provides local time TDateTime (including
DST, as is on Windows), and DateTimeToStr() etc. expect a local time
argument, a full emulation of these functions has to be provided on
other platforms as well.
But even in Delphi the programmer has to keep track whether a TDateTime
contains a local or UTC based time value (e.g. if he converted the local
time returned by Now to UTC).
Right, just like the user currently must remember whether an AnsiString
contains Ansi or UTF-8. But how do you want to get the UTC and put it
into a TDateTime?
And functions like DateTimeToStr don't care whether a time value is
local or UTC and in my opinion they even MUST NOT.
Splitting the TDateTime into year, month etc. is done by a DecodeDate...
function, that *assumes* that TDateTime contains a local time. When you
feed it an UTC time, the result is unusable.
If I use such a
function I want the value of the given TDateTime printed to a string no
matter what timezone I'm currently in.
A TDateTime only contains the number of days since the begin of the
epoch (of the encoded date). Which epoch should apply?
The time part contains the fraction of the day, based on midnight of
which timezone?
DoDi
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
