Jarkko Hietaniemi wrote:
>
> As I said the problem isn't the p52p6 doing that kind of transformation.
> The problem is someone familiar with perl5 writing code in perl6:
>
> if (my $fh = open(">/tmp/$$".time())) {
>
> and later something crashing and burning because some other place expects
> to find a filename of the form /^\d+\d+$/, or someone printing into log files
> like this
>
> print LOG time() . ": gorkulator borked. Please investigate."
>
> and someone splitting on /\./, etc.
Good point, this is a problem with changing time() from UNIX epoch (or
anything else which provides sub-second granularity or otherwise
introduces a ".").
> > 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?
>
> Some sort of less C/UNIX-centric way would be nice, yes.
We had a whole ton of discussions on this regarding "what epoch is the
right one", and the general consensus was that we should keep time()
as-is. The basic argument went like this:
1. All epochs are arbitrary
2. The UNIX epoch is well-known and understood
3. Therefore let's not mess with it
In fact RFC 99 proposed the reverse - that all platforms should use the
UNIX epoch. There was about a 50/50 split, some said "Why mess with
MacOS?" and others said "This would help Perl cross-platform." See RFC
99 at http://dev.perl.org/rfc/99.pod
The full discussions, which included ponderings of Modified Julian, the
ISO format, etc, can be found starting at the following places:
Original proposal to use MJD and introduce mjdate(), which
resulted in much heated slashing and burning:
http://www.mail-archive.com/perl6-language@perl.org/msg02171.html
Reintroduction as standardizing on UNIX epoch:
http://www.mail-archive.com/perl6-language@perl.org/msg02308.html
General slashing and burning of the UNIX epoch idea:
http://www.mail-archive.com/perl6-language-datetime%40perl.org/msg00029.html
Since there were many replies your best bet is to read the "Follow-ups"
at the bottom rather than hitting the "Next Thread" button.
-Nate
