On Fri, 20 Feb 2009, Timothy S. Nelson wrote:
Format specifiers - this could come from locales (CLDR specifies this)
or strftime, but again, it's more complicated than is needed
[snip]
Added iso8601 output for every role, and made that the
stringification. ISO8601 is unambiguous world-wide, easy to read, and
easy to output.
I'm quite keen to have something here as a formatter. I was hoping
for CLDR, but I'd be happy with even a subset of CLDR that does what we want.
Or even, failing that, with the ISO8601 part being implemented as a
formatter.
I really don't think this is a good idea. CLDR is complicated _and_ likely
to change in the future, as it's defined by a spec which we do not
control.
It's also entirely oriented around locales, so to do it even vaguely
properly we'd have to at least include a locale, and which one would that
be? en-US?
Again, locales are complicated and subject to change.
If there _must_ be a formatter (which I don't think is necessary), I'd
suggest it be based on the Unix strftime. Except that still has some
locale-specific bits. However, generally you can get the system itself to
implement this for you.
+ # These always return the long English names
+ method month-name () returns Str; # "January"
+ method day-name () returns Str; # "Tuesday"
This is one reason I was wanting a formatter -- then we wouldn't need
all these functions. People could just go $time.format('MMMM') and get what
they want. Like I said though, the core might be better off with a subset of
CLDR that does month name, day name, and the ISO8601 stringification.
I like those methods because they're fluent and easy to read. I think
forcing people to use a formatter for common, trivial cases is gross.
OTOH, I think the name returning methods could be dropped from core
entirely.
DateTime math
=============
removed all references to ...
[snip]
Any sort of date or time math
[snip]
Got rid of all mutating operators on everything. The built-ins should
be immutable for simplicity.
Date/time math was something else I'm also very keen to have. The
other built-ins play happily with operators -- why wouldn't the temporal
ones? By "mutating operators", do you mean "multi operators"? If so, I urge
you to:
No, by mutating I mean anything which changes the object. As I said, I
think it's best that the built-ins be immutable.
Renamed Temporal::Instant to Temporal::DateTime
Hmm. We had some mailing list discussion about this, and agreed on
Instant. I'd like to see your reasons in favour of DateTime.
Because DateTime makes sense and is a clear description of what the thing
is. Instant is incredibly ambiguous, and not a common term for such
things.
One of my (unmentioned) reasons for not calling it DateTime is that I
was expecting the CPAN module to be called DateTime, and didn't want to stamp
on any names. But that's not as high a priority.
But this is a bunch of roles. If I upload something called just "DateTime"
to CPAN6, it better do this role, right? That's part of the reason I'm
trying to keep things really simple.
Added numification overloading for Temporal::DateTime, which gives us
comparison for free.
Cool :).
In case I didn't say this elsewhere, I'd be happy to see localtime
and gmtime disappear in favour of other temporal constructors. And surely
time() could be merged in as well?
I'm sure there could be one constructor as a language built-in, time being
a reasonable candidate. But I can also see the value of having two, one
for UTC and one for local time.
-dave
/*============================================================
http://VegGuide.org http://blog.urth.org
Your guide to all that's veg House Absolute(ly Pointless)
============================================================*/
