On Fri, 20 Feb 2009, Dave Rolsky wrote:
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
Ok, I was unaware of these bits of information; request withdrawn.
+ # 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.
Fine by me :).
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.
Ok, I understand what you're saying now. Not sure I agree, but I
doubt others agree with me, so I won't bother arguing :).
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.
Hmm. Ah, I can see why it's ambiguous. For those who missed it,
think of what "instant" means in the context of "Instant coffee". I think I
still slightly prefer "instant", but I don't mind much any more :).
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.
Oh, I agree on retaining the functionality, I just don't think we need
them as separate functions (ie. ones listed in the revised S29).
---------------------------------------------------------------------
| Name: Tim Nelson | Because the Creator is, |
| E-mail: wayl...@wayland.id.au | I am |
---------------------------------------------------------------------
----BEGIN GEEK CODE BLOCK----
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V-
PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI++++ D G+ e++>++++ h! y-
-----END GEEK CODE BLOCK-----
