Front page | perl.perl6.language |
Postings from January 2001
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! - BrandenThread Previous | Thread Next