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.
