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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
