> Anyway, it doesn't matter; it's a lot more widely used than any other
> epoch, and epochs are completely arbitrary anyway. What's wrong with it?
I think the "What's wrong with it?" part is the wrong approach to this
discussion. Personally, I'm a 100% UNIX head. All I work on is UNIX
(thank heavens). And that's all I even plan on using; after all, I'm a
UNIX sysadmin. So, time() actually makes more sense to me than mjdate(),
even though I proposed the RFC.
That being said, what we need to say "is it possible UNIX might not be
perfect?" (hard to imagine, true... :-). More specifically, "is there
something that would work better for putting Perl in Palm pilots,
watches, cellphones, Windows and Mac hosts, *plus* everything else it's
already in?"
> Is Perl currently using different epochs on different platforms?
No, but currently Perl IS forcing Windows, Mac, and BeOS users to
understand what the UNIX epoch is.
There's some other advantages to MJD beyond system-independence. Namely,
it allows easy date arithmetic, meaning complex objects are not required
to modify dates even down to the nanosecond level.
One thing C has done well that we can learn from is making libraries
system-dependent, but the language system-independent. Leave time() and
localtime() (UNIX dependent) in Unix::Time or some other module, easily
accessible through a "use Unix::Time". But make the core language easily
accessible to everyone. That's where mjdate() comes in, IMO.
-Nate
