Larry Wall wrote:
This still seems to be confusing implementation issues with the point
I'm trying to make about the basic nature of time.

Duration and Instant are both simple (but typed) Num semantics
on seconds.  There are no integers unless you specifically ask for
an interpretation in minutes, hours, fortnights, what have you.
The basic flow of time is continuous and stable in Perl 6, or as
continuous and stable as we can make it.

I couldn't agree more with this, and that's certainly how we want to look at things as a generic conceptual or practical foundation.

I also take back my stated preference of the internal format being in terms of YMDHIS due to stored future date values continuing to DWIM over time.

I now think that a simple Num that counts seconds from some rigorously defined epoch, and I mean rigorous with the kind of rigor that the duration of a second is currently defined in terms of a cesium-133 atom at a particular temperature within gravity of a particular strength; for that matter, Perl 6 should explicitly define what a second is as well, though it can and probably should just punt and refer to "what it says in <the particular official standards document>".

And so, to deal with my concern about DWIM, what we probably want is some other data type that represents a lazy conversion to the internal type from whatever interpretation the user wants; that is, the alternate type would, eg, use YMDHIS internally, which is stored for persistence, so to DWIM for the user. And this alternative can be punted to the domain of CPAN modules.

In contrast, the simple Num-from-rigorous-epoch approach works when you want to deal with current-time, time-stamps, stopwatches, any kind of serious math or physics etc, where it is really the relative time of events relative to each other that is important, and not where they fit on a human calendar.

Only atomic time in atomic seconds will be futureproof over the long
haul.  All other interpretations are negotiable via libraries, but
time must be considered a position on a real timeline, and seconds
are a reasonable unit for measuring that timeline.  The method in
$duration.seconds should not have to do any calculations to return
the Num number of seconds, because whether we're talking about
gigaseconds or femtoseconds, we're still talking about seconds.

Time has no relationship to integers apart from cultural artifacts.
Let's keep our integers in the libraries, not in the fundamental
definition of what "now" and "then" mean.

Yep, couldn't agree more.

-- Darren Duncan

Reply via email to