On Mon, 14 Aug 2000, Nathan Wiger wrote:
> 1. time() would still return UNIX epoch time. However, it
> would not be in core, and would not be the primary
> timekeeping method. It would be in Time::Local for
> compatibility (along with localtime and gmtime).
>
> 2. mjdate() would return MJD. It _would_ be in core, and
> it _would_ be the internal timekeeping method. All
> of the new date functions would be designed to be based
> off of it.
>
> So, just to clarify:
>
> 1. The Perl 5 way in Perl 6:
>
> use Time::Local;
> $date = localtime time();
>
> 2. The Perl 6 native way:
>
> $date = date mjdate();
Now, are we talking about the new default/de facto standard that the
users are being presented with? Or are we talking about the true
internal structure? ("and it _would_ be the internal timekeeping
method.")
I don't have an OS that reports time in MJD. It seems
counter-productive (IMHO) for Perl (internally) to convert from
whatever the native platform time measurement is to MJD, only to
convert it back to the native format again, if that never is presented
to the users.
For example:
# From 5.6 perlfunc
$now = time;
utime $now, $now, @ARGV;
Under this proposal, time would (under Unix), return the number of
epoch seconds, which would then be converted to MJD internally. This
stored MJD would then have to be converted back to the original epoch
seconds, (perhaps twice), for the argument to utime? Alarms and
timers, file tests - any time interface outside of Perl itself - these
*all* will be converted to MJD internally?
(Assuming, of course, that you don't explicitly change the arguments to
utime to accept MJD, although it would still have to be converted to
native format anyway.)
I can understand wanting to present the user with a common,
multi-platform, consistent date/time interface, but I don't understand
extending that to the internals.
--
Bryan C. Warnock
([EMAIL PROTECTED])
