[fpc-devel] Problem with Now() and time changed by ntpd

[Hans-Peter Diettrich]

Vinzent Höfler schrieb:
> On Wed, 02 Nov 2011 07:35:30 +0100, Felipe Monteiro de Carvalho 
> <felipemonteiro.carvalho at gmail.com> wrote:
> 
>> Maybe that would be something interresting to add. Programs that want
>> to measure time differences could use it instead of hacking Now.
> 
> Well, all what's needed is to differentiate between a political-time
> and a monotonic/real-time clock.
> 
> The latter could be sufficiently substituted on all systems by the
> underlying facilities of the system with opaque time types. The RTL
> could provide all necessary conversion functions, so not even the
> actual resolution of the system would matter.

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 Delphi also offers a (monotonic) modified Julian date (type Double), 
and TTimeStamp, and conversions are required when such values shall be 
formatted into strings. With overloaded functions the monotonic/local 
time conversion can be performed in the formatting etc. functions, and 
specialized functions to get the time in other encodings can be added.

Another feature could switch the application-wide TDateTime content, 
between local (Windows default) and monotonic/UTC (POSIX) time. This 
would not require additional functions, instead all date/time functions 
would take into account that setting internally. Drawback is that only 
one encoding can be used in an application, i.e. the user must decide 
whether times are used as unique (monotonic, real-time) time stamps, or 
in local time for display purposes.

As a third solution the time encoding could be added to TDateTime, 
similar to the new AnsiString encoding. Care must be taken to keep such 
an extension compatible with e.g. typecasts (Double from/to TDateTime). 
Perhaps a conversion of TDateTime into an Object with an added Encoding 
property would help...

DoDi