On Sun, Apr 25, 2010 at 02:31, Doug McNutt wrote:
> Agree on a format for storing fractional atomic seconds. There are
> proposals for two word integers with one of them being micro or nano seconds
> and the other seconds. I prefer IEEE floating point with atomic seconds as
> the unit of measure
At 21:09 -0700 4/23/10, Darren Duncan wrote:
>I think that the most thorough solution is to just take it for granted that
>there are multiple reference timelines/calendars and that in general it is
>impossible to reconcile them with each other.
At 15:46 -0700 4/24/10, Darren Duncan wrote:
>All d
Jan Ingvoldstad wrote:
On Sun, Apr 25, 2010 at 00:46, Darren Duncan wrote:
All details specific to any calendar, including Gregorian, including
concepts like seconds or hours or days, should be left out of the core and
be provided by separate modules. Said modules can be self-contained, just
s
Absolutely ridiculous. The Gregorian calendar is in universal use for
civil purposes and definitely belongs in the core.
On Saturday, April 24, 2010, Darren Duncan wrote:
> I want to clarify that I currently believe that the Perl 6 core should only
> include temporal roles and *no* temporal cla
On Sun, Apr 25, 2010 at 00:46, Darren Duncan wrote:
> All details specific to any calendar, including Gregorian, including
> concepts like seconds or hours or days, should be left out of the core and
> be provided by separate modules. Said modules can be self-contained, just
> say using Perl's or
I want to clarify that I currently believe that the Perl 6 core should only
include temporal roles and *no* temporal classes. So the Perl 6 core could
provide, say, 3 roles, Instant, Duration, and Calendar (or use some other name
for the last one). It would also provide now(), sleep(), and cal
Jon Lang wrote:
Darren Duncan wrote:
I think that the most thorough solution is to just take it for granted that
there are multiple reference timelines/calendars and that in general it is
impossible to reconcile them with each other.
Taking this to its logical extreme, there might be a few (ad
Darren Duncan wrote:
> I think that the most thorough solution is to just take it for granted that
> there are multiple reference timelines/calendars and that in general it is
> impossible to reconcile them with each other.
Taking this to its logical extreme, there might be a few (admittedly
fring
Jon Lang wrote:
Why do I find myself thinking of roles and classes here?
IMHO, we should have a role that represents abstractly a moment in
time. This role should, in and of itself, not be tied to any
particular calendar; its purpose is so that one can write functions
that make reference to ins
Why do I find myself thinking of roles and classes here?
IMHO, we should have a role that represents abstractly a moment in
time. This role should, in and of itself, not be tied to any
particular calendar; its purpose is so that one can write functions
that make reference to instances in time wit
Minor nit:
On Apr 21, 2010, at 04:57 , Richard Hainsworth wrote:
If a calendar system, eg., Chinese, Muslim and Jewish, defines days
in the same way, eg., starting at midnight and incorporating leap
seconds, for a time-zone, then the naming of the days is done by
The Jewish, Muslim, and Bah
On Wed, 21 Apr 2010, Mark J. Reed wrote:
I recommend not to open this up for 6.0.0 core. Calendar conversion
is easy to do in a module, and the Date class has an absolute day
count, which is really all you need everything for an intermediate
representation. It wouldn't be hard to port Calendr
I recommend not to open this up for 6.0.0 core. Calendar conversion
is easy to do in a module, and the Date class has an absolute day
count, which is really all you need everything for an intermediate
representation. It wouldn't be hard to port Calendrica, for
instance.
Also, the difference bet
I whole-heartedly agree that we need to make a system independent of any
sort of time measurement system. I think the conclusion reached on IRC
was that most of the world uses or is at least familiar with the
Gregorian system.
Now, I can't help but think how we would define an Instant. The bes
In reading all of the discussion about Temporal, I have the uneasy
feeling that the current development work is falling into the same traps
as other languages. It seems to me that the underlying time-measurement
paradigm of the developers is too tightly focused on the Christian
Gregorian calend
15 matches
Mail list logo