On Fri, 20 Feb 2009, Richard Hainsworth wrote:
a) I am strongly in favour of "Instant" over "DateTime" for several reasons,
one being that it marks a new approach.
I don't care _that_ much. I'm happy to leave it to @Larry.
b) Although for business we use a calendar derived from the one decreed by
Julius Caesar, via Pope Gregory, additional days, and leap seconds, there are
many calendars in use, and there is no overwhelming logical reason why a
different calendar might not be used in the future. For the interested, the
Jews, Muslims, Baha'is and Chinese all use different calendars.
Yes, and this will be a great thing for CPAN6 ;)
c) Fixing the core6 time processing functionality to a specific calendar is
restrictive, whereas focussing on an underlying handling of time using an
accepted synchronisation standard allows for easier extensions.
d) This would mean that the functionality of dates should be handled by
modules.
Thus Temporal::Gregorian would include functionality that leads to years
from 1AD, 7 days of the week, 12 months with unequal day lengths, days
starting at midnight, and a mapping from the core perl6 values to current
calender values, eg. 20 Feb 2009.
Having a default set of roles that is Gregorian makes sense. It's the
world-wide standard, and has been for about 100 years or so. There's no
good reason to think that this will change in the lifetime of Perl 6.
e) Perhaps we could define the minimum time functionality in core perl6 by
some set of principles:
- attributes that will allow time keeping within a program;
- attributes that provide access to a global synchronisation standard;
- attributes that make it easy to map the global synchronisation onto a given
calendar structure;
- duration measuring (basic stopwatch functionality).
f) Date arithmetic is calendar-related because
$days_2_Xmas = Date('25 Dec 2009') - today();
requires information about the structure of months dependent on the year, but
it is also related to synchronisation to provide the today() term.
g) Depending on the software needs, date arithmetic can be simple, only
dealing with the next few years. Other times, it needs to be more complex, to
handle dates across centuries. Hence, there would be
Temporal::Gregorian::1907AD, Temporal::Gregorian::1AD etc.
I don't really follow this part.
h) Time functionality seems to me to need both immutable parts, viz., links
to the global synchronisation, and mutable - timezone and daylight saving. (I
would include these as part of the time-keeping part of the system). The time
of day depends on the position of the computer, but not on the calender date.
But if software is being written to be used on a portable or travelling
computer, there needs to be the means to change these offsets, perhaps as the
software is running.
A timezone _observance_ is not mutable. An observance is associated with a
specific datetime. If the datetime changes, the observance should change,
but this is a complicated thing to handle. If the datetime is immutable,
then this is a non-issue.
-dave
/*============================================================
http://VegGuide.org http://blog.urth.org
Your guide to all that's veg House Absolute(ly Pointless)
============================================================*/
