"Stephen P. Potter" wrote:
>
> Why do we have to worry about changing time()? There's a real parallel
> between sleep() and alarm(), so we would want to do both if we did either,
> but time() really has no relation to them.
>
> Or, should we just implement usleep() and (for lack of a better name)
> ualarm()?
One thing that was discussed on the archives that I sent out was
introducing a parallel mjdate() (or isodate() or whatever) which gave
access to the internal means of maintaining time in Perl. Then Perl's
internal clock could be sub-second ticks since 4152 BC, Modified Julian,
etc, etc.
So time() could remain unchanged (from a language/user perspective, at
least), but sleep() and alarm() could use the internal sub-second
methods of timekeeping to DWIM. The user gets sleep(0.5) and time() is
still epoch seconds.
But the big problem is that there's a lot of stuff that's based off of
time() right now, like stat(), lstat(), etc, etc. When you think of the
cascading effects of changing Perl's timekeeping it gets really, really
sticky.
If the internal timekeeping were changed, one thing that's apparent from
the discussions is that there would *have* to be a core way of providing
exactly what time() does currently or lots of stuff would break really
badly. Someone can certainly chime in if they see an easy way around
this, but as I recall there was little disagreement on this point.
-Nate
