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

[Marco van de Voort]

In our previous episode, Henry Vermaak said:
> >> saving time changes? ?If they don't use shared memory for this, I'd
> >> wager that it's just as slow as libc localtime.
> >
> > I doubt Windows has a _file_ based concept of timezone.
> 
> Explain?

It has an in memory concept of timezone, and doesn't have to poll files on
the filesystem for timezone changes.
 
> > And I agree with him (if only because my business app would break horribly.
> > Worse, if my business app ran on Linux, rescanning the timezone files in
> > a thread that called gettime would probably violate realtime constraints and
> > our quality assurance app would eject valid products because of unexpected
> > latency due to unforseen harddisk access.
> 
> Do you even understand how this works on linux?  'localtime' stats the
> file to see if the timestamp has changed, only then does it reload
> from the file. 

That would be the primitive way, inotify would make more sense though might
not work universally on all filesystems. 

But do you agree that _when_ it happens, the directory is rescanned in the same
thread as the gettime() call, outside programmer's control? And that that
breaks code for people that don't expect the runtime to access the harddisk
without they explicitely solicating that? (e.g. to preserve some realtime
behaviour(*))?

Because that was my point.

> It doesn't read the file every time.  If you're timing
> things, you are doing it wrong.

Explain.

> If it's more important to you to be
> fast than correct, then you can weigh up the risks yourself, just
> don't force it upon all the users of the freepascal compiler.

That is an symmetrical argument. I could argue exactly the same about
correctness. I don't need it, so please don't force it on all users.

The fact remains that the original Windows call has *both* aspects.

> I appear to be wasting my time if two rtl developers can even consider
> that giving possible erroneous results is an option.

No. They are encouraging you to see beyond the immediate need. There is a
reason why plugin units are used so much for these kinds of issues, to not
hardcode an implementation that is satisfactory for only 90% of the users.