Re: Temporal changes (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)
On Mon, 23 Feb 2009, Martin D Kealey wrote: On Mon, 23 Feb 2009, Timothy S. Nelson wrote: 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 :). Ah, we want a noun that isn't readily confused as an adjective. Suitable terms might include: Instant Jiffy Juncture Moment Occasion Snap Tick ... The originator of "Instant" rejected "Moment" on the basis that in physics, it's used in a variety of ways such as "moment of inertia", etc. My personal feeling is that Occasion has other connotations we don't want. Anyway, $Larry has decreed that it be Instant, unless you've given him an idea above. I like jiffy, myself, but Wikipedia says "In computing, a jiffy is the duration of one tick of the system timer interrupt". If we take that as gospel, we probably want to avoid it. I'd also avoid calling something "Snap" unless it breaks :). Tick has similar problems to Jiffy. I don't know anything about Junctures, except that the potential for confusion with the Perl6 feature "Junction" is huge. IOW, none of them are perfect :). - | 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-
Re: Temporal changes (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)
On Mon, 23 Feb 2009, Timothy S. Nelson wrote: > > > > 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 :). Ah, we want a noun that isn't readily confused as an adjective. Suitable terms might include: Instant Jiffy Juncture Moment Occasion Snap Tick ... -Martin
Re: Temporal changes (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)
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('') 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-
Re: Temporal changes (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)
On Fri, 20 Feb 2009, Dave Rolsky wrote: > > > 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. I think people are starting to argue at cross purposes here. An instant and a date-time are NOT the same thing. Barring limitations imposed by the speed of light and aberrations caused by relativity, and an instant occurs everyone at the same time. A date-time, if it's really true to its name, represents some 40-ish different instants, depending on which timezone it's interpreted in. At some point you have to decide which fictions are useful vs where you really need to hold out for reality. * First fiction: the speed of light is infinite, so instants really are universal. Unless you're writing GPS control software, you're probably OK with this. * Second fiction: the earth rotates at exactly 1/1440 rpm, so UT1=UT. POSIX's "epoch seconds" pretty much enforce belief in this, so if you don't want to believe it, you're going to have to build your own time libraries from scratch. * Third fiction: the day matches the rotation of the earth. In some places the law requires you both to believe and disbelieve this simultaneously. (For example, it may require that you're billed 10 minutes for a phone call that started at 01:55 and finished at 03:05.) * Fourth fiction: it's legally the same time everywhere on earth, especially for registration of births, deaths and marriages. (For example, if I move from my native New Zealand to, Hawaii, I will 23 hours older at my next legal birthday than I would be if I remained in NZ. Probably I'd be a day younger when I die too.) * Fifth fiction: everyone speaks English. It seems there is scope for multiple types, starting with Instants (which must believe fiction 1 and may or may not believe fiction 2), DateTime (which is agnostic about fiction 3), and "Localtime" and "Date" (which believe fictions 3 and 4). For each of these you have corresponding variants of Duration. So my question is, which of these fictions should the core temporal type(s) believe or disbelieve? Then we should name them appropriately. -Martin PS: IMHO core types should believe 1 & 2, and disbelieve 3 & 4, and avoid doing anything that depends on believing 5.
Re: Temporal changes (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)
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('') 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)
*/
Re: Temporal changes (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)
On Fri, 20 Feb 2009, Timothy S. Nelson wrote:
+role Temporal::DateTime {
+has Temporal::Date $!date handles ;
Can't do this, I think; this would require an instance of
Temporal::Date, which is a role and can't be instantiated. That's why I was
using "does" instead. I don't know what the alternative is, but I'll leave
that to you :).
Ok, I'm wrong here; sorry :).
-
| 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-
