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
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 ...
Any sort of date or time math
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.


http://VegGuide.org               http://blog.urth.org
Your guide to all that's veg      House Absolute(ly Pointless)

Reply via email to