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.


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

Reply via email to