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

Reply via email to