Timothy S. Nelson wrote:
Conceptually, I agree. But there are places that Time::Piece assumes
time is a sane thing, and it just isn't. Date::Time has a less DWIM
interface, but is much more correct in the face of general human
nuttiness on this topic (especially with regard to durations and
timezones).
I'd prefer to generally follow Date::Time, with DWIM features cherry
picked from Time::Piece as long as they don't result in wrong behavior.
Agreed, and that's kinda what I'm doing. But I still think there's
room for improvement. I'll try and design an API that does what
DateTime does, but:
1. Uses more variables, of which I expect the getters and setters to be
overridden.
2. Documents in terms of operator overloading
3. Depends a lot more on CLDR formats
4. Doesn't have multiple functions that perform exactly the same thing
5. As a consequence of all of the above, has a lot fewer functions
(while
still providing all the same functionality).
Talking about dates and times, I have some suggestions.
First of all, I don't think that most DateTime stuff belongs in IO. The class
definitions to represent a date or time or duration etc value, as well as
operators to convert date formats etc or add/subtract etc dates are strictly
internal, same as number or string operations. Only the routines to fetch the
current system time and the like belong in IO, or routines concerning file
timestamps etc.
Second of all, I think a more generic term than DateTime should be used to name
an object that represents an instant in time; for example I suggest calling it
"Instant". The name "Instant" fits in a lot better in the company of other
generic sounding temporal data types like "Duration" etc. Then, you can say
that things like DateTime, Date, Time, etc are subtypes of Instant.
See also http://search.cpan.org/dist/Muldis-D/lib/Muldis/D/Ext/Temporal.pod
where I've specced out such matters, and that illustrates something I recommend
for you. My Instant types very closely resemble both the Perl DateTime library
as well as the SQL temporal types, which are actually very similar, though I've
generalized it a bit. This spec explicitly does not support time zones (it has
UTC or floating, that's it) and it doesn't include conversions with strings, but
it has the foundation on which such could be built. And yours doesn't have to
be the same of course.
-- Darren Duncan
