On Tue, 1 Nov 2011, zeljko wrote:
On Tuesday 01 of November 2011 11:01:32 Sven Barth wrote:
> On 01.11.2011 09:41, zeljko wrote:
> > I don't believe that kernel have only gettimeofday() and that kernel
> > don't know accurate datetime. There's more functions in kernel which can
> > give you accurate result. gettimeofday() is deprecated, so maybe that's
> > main reason why it fails to give correct result with daylight changes.
>
> Out of curiosity: Where did you get that gettimeofday is deprecated?
somewhere in /usr/include ... or time.h or sys/time.h
The problem is not in gettimeofday. The problem is in the timezone information.
The clock functions are just a more elaborate form of gettimeofday, they introduce
nothing fundamentally new.
Using clock_gettime will not help, since it returns the same time as
gettimeofday,
namely the elapsed time since the Epoch.
It expliticly says in the man page of clock_gettime:
"When its time is changed, timers for a relative interval are unaffected,
but timers for an absolute point in time are affected."
As stated, the problem is the time-zone and DST information. The kernel has no idea
about time zones, it just keeps ticks since the epoch. All applications must convert
the time returned by gettimeofday or clock_gettime to local time. For this, they use
the information in the timezone files.
We'll simply need to store the next moment when the DST correction changes, compare
the result of gettimeofday with that and re-base the time calculation. If we decide
to add some check for the timestamp of the timezone file - that would make Date(),
Time() and Now() VERY expensive operations.
All the above is the reason that high-speed loggers simply store the result of gettimeofday
in the logs.
Michael.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
