Jarkko Hietaniemi wrote:
> I guess it's part of the can of sub-second worms: if we do sleep(),
> people will ask why don't we do time() and alarm(), too. sleep() and
> alarm() we could get away with more easily, but changing time() to do
> subsecond granularity would be A Bad Thing for backward compatibility.
> Think of generated filenames, or various logs with timestamps. We can
> (hopefully) do a magical p52p6 translator, but fixing the existing
> data is a tad harder.
I see no trouble in time returning a float value. p52p6 could translate
time() to int(time()) and everything should work ok. Anyway, time is
probably gonna change in perl6, since it's UNIX-based now and i think
we no longer have to know how many seconds have passed since mid-night
january 1st 1970, do we?
Also, we could translate the stringified result of the float value of
time to be the string of only the integers, what would probably solve
the log timestamps problem, but as it would also be solved with
int(time()), I won't consider it here, since it can lead to not DWIM,
IMO.
For reference, see RFC 99 on standardizing time to (oops!) UNIX-time
(even so, my point continues, int(time()) solves p52p6 problem!),
RFC 73, on making all built-ins return objects, which would do the
stringifying thing or even allow with and without fractions in one
object, and RFC 48, on changing localtime() and gmtime(), 'cause
maybe time() will go with them too!
- Branden
