At 3:36 PM -0700 7/5/05, Dave Whipp wrote:
Darren Duncan wrote:
The object should not store anything other than this single
numerical value internally (smart caching of conversions aside).
I think we can all either agree with that, or dont-care it. The
internal implementation is an implementation issue (or library). It
doesn't need to be defined by the language. The one important thing
is that that language shouldn't define semantics that require more
than this single value (e.g. we shouldn't associate the epoch with
the object).
What I'm saying is that the epoch for a high-precision-knowledge date
is effectively hard-coded into Perl as a "standard" and users do not
specify it or override it at any time. If this is accepted, then all
that's left to discuss for these types of dates is what list of
conversion methods there are and accepted input/output formats.
Which perhaps is the point. The main reason implementation would
have a say is if Perl's built-in functions do not return the
Date/Time object, but some scalar information instead like Perl 5.
But I say it should return the object. -- Darren Duncan
