Dave Rolsky wrote:
After some discussion I made a number of drastic revisions to S32-setting-library/Temporal.pod

What I want to see in Perl 6 is a set of very minimal roles that can be used to provide a simply object from gmtime() and localtime(). These objects should not handle locales, proper Olson timezones, string parsing, user-defined formatting, or math.

They're basically simply little data blobs with some overloading and a few handy methods.

I imagine that a real classes which do math, handle leap seconds, formatting, and so on will _also_ do these roles, but this should be done out of core.
Some comments arising from reading the ensuing threads/emails:
a) I am strongly in favour of "Instant" over "DateTime" for several reasons, one being that it marks a new approach. 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. 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. 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. 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. i) It seems to me that the core should give access to years, days, minutes, seconds from the standard. Then some time arithmetic will be possible in terms of these units. Given the use of leap seconds, these measures may not be exact multiples. j) A question to the list: to what extent are sub-second intervals from the start of the era needed? I can see the need for sub-second granularity when measuring durations, eg., how long a subroutine takes to run. But I cant see the need for sub-second granularity in knowing the current time. It seems to me that the two are different. k) The reason for the question above is that whereas synchronisation units (eg., seconds since the start of era) should always be defined, subsecond attributes need only be defined for duration measurements (stopwatch functions). l) The definition of the attribute that holds subsecond information (viz., number of nanoseconds, or fraction of a second) seems to me to be be moot. We require a specification decision, eg., perl6 allows duration timing accurate at least to nanoseconds. Even if subseconds are fractional at some point the decimal places, even though they can be printed, would have no physical meaningfulness. In the problem domains where femtoseconds can be meaningfully measured and manipulated, specialised software will be needed in any case. If, moreover, it becomes necessary to specify some other accuracy, then that will be a part of perl6.2001 :) Since the meaningful precision is defined, I think it would be easier for there to be a stop-watch attribute that is defined to be in (eg) nanoseconds.

Sorry for the length.

Reply via email to