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

[Sven Barth]

On 31.10.2011 20:32, zeljko wrote:
> On Monday 31 of October 2011 20:17:46 you wrote:
>
>  > On Mon, 31 Oct 2011, zeljko wrote:
>
>  > > Hi,
>
>  > >
>
>  > >
>
>  > > I have daemon which uses Now() for getting current date/time, but
>
>  > > something is wrong, time on server changed from 03:00 to 02:00 this
>
>  > > weekend, but daemon's Now() was on old time ... until now ... I've just
>
>  > > restarted it and now it applied new time.
>
>  > >
>
>  > > fpc-2.4.5, centos 5.5 ....
>
>  > >
>
>  > > Also this confirms something what happens sometimes when ntpd changes
>
>  > > time ...
>
>  > >
>
>  > > Any hints ? What to do ? Any workaround ?
>
>  >
>
>  > It's probably the timezone information which is loaded only once at
> program
>
>  > startup.
>
>  >
>
>  > This has been reported before, but no satisfying solution was found
> at the
>
>  > time. re-reading this file at each now() would be extremely slowing.
>
>
> hm... dcc (kylix) uses localtime_r and this is from man page of that
> function.
>
>
> The localtime() function converts the calendar time timep to broken-time
> representation, expressed relative to the user's specified time zone.
>
> The function acts as if it called tzset(3) and sets the external
> variables tzname with information about the current time zone, timezone
> with the difference between Coordinated Universal Time (UTC) and local
> standard time in seconds, and daylight to a non-zero value if daylight
> savings time
>
> rules apply during some part of the year. The return value points to a
> statically allocated struct which might be overwritten by subsequent
>
> calls to any of the date and time functions. The localtime_r() function
> does the same, but stores the data in a user-supplied struct. It need
> not set tzname.
>
>
> What uses fpgettimeofday() ?

fpgettimeofday uses exactly what it says on the tin: gettimeofday. See 
here: http://linux.die.net/man/2/gettimeofday

The fp* functions in Linux by default call directly the kernel instead 
of going through libc, thus avoiding the dependency on that library.

Maybe a possibilty should be implemented in unit Unix to reread the 
timezone file. This wouldn't solve your problem directly, but it would 
at least provide the ability to update the time zone information without 
restarting the application/service. The trigger would need to come from 
an external source though (maybe by checking that timezone database that 
was in the media some weeks ago).

Regards,
Sven