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