Re: Temporal revisited
Larry Wall wrote: snip 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. snip 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
Re: Temporal revisited
On 2009-Feb-20, at 7:17 am, Dave Rolsky wrote: Define really basic math. [...] you could say all math is done in terms of seconds, but then there's literally no way to add 1 month. Oh, I meant only adding or subtracting seconds (as mentioned elsewhere); adding a month is certainly advanced enough to require a module. I also think some really basic parsing would be suitable -- no more than the ability to understand strings in the same default ISO format used for displaying dates and times, e.g. my Temporal::Date $christmas = 2009-12-25; As I said in the spec, you _can_ get an observance for a given epoch value quite easily. This tells you the offset from UTC, whether DST is in effect, and a short name identifier (like CST). OK, but I wasn't sure how required it was -- shouldn't there be something to disallow an undefined observance? And plain Date or Time objects don't have a TZ observance at all. I can see that a time or date might not have a specific timezone, such as Dates for a calendar program; you'd want to be able to highlight a certain day, not a range of 24 hours that shifted as you changed timezones. But that's really a floating or lazy local TZ; the zone is defined at any given moment, it just might change if the (effective) location of the computer changes. That's still different from having no TZ info at all... although using undef to represent that floating value seems reasonable. I would still argue that however it's represented, it should be necessary to specify a fixed TZ or some special value for the floating zone. On 2009-Feb-20, at 10:01 am, Mark J. Reed wrote: Why can't we just have time() that takes a :tz adverb and dispense with gmtime() and localtime()? If an Instant object also represents a point in time irrespective of location, then there's likewise no point in a :tz adverb. Oh, of course, I was even thinking that the TZ would only be need to be specified for times coming from somewhere else. -David
Re: Temporal revisited
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.
Re: Temporal revisited
On Thu, Feb 19, 2009 at 7:26 PM, Dave Rolsky auta...@urth.org 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. I don't really know Perl 6 all that well, so I'd welcome review, in particular of my Perl 6-isms, and also just of the general concepts. Why should an Instant be a role, and not a concrete class? What would one instant do that another can't? Representing a specific moment in time sounds like a very concrete thing to me. Leon
Re: Temporal revisited
On Fri, 20 Feb 2009, Leon Timmermans wrote: On Thu, Feb 19, 2009 at 7:26 PM, Dave Rolsky auta...@urth.org 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. I don't really know Perl 6 all that well, so I'd welcome review, in particular of my Perl 6-isms, and also just of the general concepts. Why should an Instant be a role, and not a concrete class? What would one instant do that another can't? Representing a specific moment in time sounds like a very concrete thing to me. Presumably the core would also ship with a class that does the Temporal::DateTime role. However, it'd also be nice for things on CPAN6 to be able to satisfy an API that codes against these roles. I think that letting things in the core be replaceable is a good design. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: Temporal revisited
On Fri, Feb 20, 2009 at 2:39 AM, David Green david.gr...@telus.net wrote: Why can't we just have time() that takes a :tz adverb and dispense with gmtime() and localtime()? It depends on what sort of value time() returns. In the caes of Perl5, the return value is completely independent of time zone. You have to take the time zone into account only when translating to a human-readable form. In that case, it makes no sense for time() to have a :tz adverb. If an Instant object also represents a point in time irrespective of location, then there's likewise no point in a :tz adverb. -- Mark J. Reed markjr...@gmail.com
Re: Temporal revisited
I'm getting a bit lost following precisely what's being proposed. What
I'm sort of feeling is that there are two fundamental immutable types
needed: Instants and Durations:
multi sub infix:- (Instant, Instant -- Duration)
multi sub infix:+ (Instant, Duration -- Instant)
multi sub infix:- (Instant, Duration -- Instant)
, a bunch of implementation-defined constants:
our Instant $unix_epoch is const = ...;
...
, plus a bunch of formatting/coercion classes/functions (some of which
understand time zones, etc):
class DateTime is Instant { ... };
In general we wouldn't expose details such as the actual internal
implementation epoch; or what datatype is used to store Instants and
Durations. One thing we might want is a way to parameterize them to
define the precision and range that the user desires for specific
concrete objects -- if we could do this using human-friendly units (as
postfix functions), that would be good:
my Duration[ :precision(1 ns), :min(0), :max(10 weeks) ] $delta;
Is this a reasonable summary?
Re: Temporal revisited
On Fri, Feb 20, 2009 at 02:07:05PM -0600, Dave Rolsky wrote: On Fri, 20 Feb 2009, Dave Whipp wrote: I'm getting a bit lost following precisely what's being proposed. What I'm sort of feeling is that there are two fundamental immutable types needed: Instants and Durations: multi sub infix:- (Instant, Instant -- Duration) multi sub infix:+ (Instant, Duration -- Instant) multi sub infix:- (Instant, Duration -- Instant) Of those three, I think only the first is really required for core, so you can do stopwatch type calculations. They can all three go in core, because... If the Duration is just seconds, the latter two are fairly useless and broken. If it's not just seconds, the math is much more complicated, and that's not the sort of thing that belongs in core. 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. Hence our ideal timeline will be strict atomic time in TAI, and machines that don't have access to the current atomic time will have to approximate it as best they can. They're already broken anyway, in my opinion. 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. Larry
Re: Temporal revisited
On Fri, 20 Feb 2009, Larry Wall wrote: 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. Hence our ideal timeline will be strict atomic time in TAI, and machines that don't have access to the current atomic time will have to approximate it as best they can. They're already broken anyway, in my opinion. 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. As long as there's no attempt to provide math beyond add this many seconds to this many seconds, it's probably safe. That will make it clear that there's no way to calculate one month from today using the core API. What I'm really trying to avoid is something like the Perl 5 Time::Seconds Time::Piece combo, where the former defines a constant of ONE_MONTH so you can do: my $time = Time::Piece-new( ... ) $time += ONE_MONTH; But since ONE_MONTH is defined in terms of seconds, this is completely broken. Of course, if you're dealing with TAI only, you're safe for constants up to ONE_WEEK. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: Temporal revisited
- Original Message - From: Dave Rolsky auta...@urth.org That will make it clear that there's no way to calculate one month from today using the core API. one month from today is ill-defined regardless what time system you are using. There are dates from which one month from today can be reasonably argued to be any of 5 different days. This is why bank contracts are always to be written to say 30, 60 or 90 days not 1, 2 or 3 months from now. -- Mark Biggar%0D%0Amark%40biggar.org%0D%0Amark.a.biggar%40comcast.net%0D%0Ambiggar%40paypal.com
Re: Temporal revisited
On Fri, 2009-02-20 at 15:33 -0600, Dave Rolsky wrote: Of course, if you're dealing with TAI only, you're safe for constants up to ONE_WEEK. So we just define ONE_MONTH as 4 * ONE_WEEK, right? *duck* -'f
Re: Temporal revisited
On Fri, 20 Feb 2009, mark.a.big...@comcast.net wrote: one month from today is ill-defined regardless what time system you are using. There are dates from which one month from today can be reasonably argued to be any of 5 different days. This is why bank contracts are always to be written to say 30, 60 or 90 days not 1, 2 or 3 months from now. It is ill-defined, but a good API can make something reasonable out of it. I refer you to DateTime and DateTime::Duration, which provide a reasonable API for this. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: Temporal revisited
Assuming the Gregorian calendar, one month from today is well defined for 98.15% of all dates, and there are a few logical options for the other 1.85%. It's true you can't define one month as a constant amount of time, but providing a method to return one month after a given date is a reasonable thing to do. On Fri, Feb 20, 2009 at 5:58 PM, Dave Rolsky auta...@urth.org wrote: On Fri, 20 Feb 2009, mark.a.big...@comcast.net wrote: one month from today is ill-defined regardless what time system you are using. There are dates from which one month from today can be reasonably argued to be any of 5 different days. This is why bank contracts are always to be written to say 30, 60 or 90 days not 1, 2 or 3 months from now. It is ill-defined, but a good API can make something reasonable out of it. I refer you to DateTime and DateTime::Duration, which provide a reasonable API for this. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */ -- Mark J. Reed markjr...@gmail.com
Temporal revisited
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. I don't really know Perl 6 all that well, so I'd welcome review, in particular of my Perl 6-isms, and also just of the general concepts. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: Temporal revisited
On 2009-Feb-19, at 11:26 am, Dave Rolsky wrote: 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. Yes; I myself haven't had to worry about leap-seconds before, and may very well never have to. Really basic math is common enough that it seems reasonable to include, though. And we get that by being able to numify times, though I'm not sure about officially making time() return a Num -- isn't that exposing an implementation detail? If I need an epoch value, I'd expect to have to say $time.epoch or $time.epoch(1970) or something. our Time::localtime(:$time,:tzGMT) Why can't we just have time() that takes a :tz adverb and dispense with gmtime() and localtime()? I also think that timezones should be required, so that it's impossible to have a time and not know what TZ it's supposed to be. If there's no simple enough way to do minimal timezones, then allow only GMT (and require using a suitable module to recognise any other TZ). If you really don't care because you know for sure the TZ will never matter, say use timezone GMT. (You may as well not care that all the times are GMT in that case. But if it turns out someday that you do care, you can't say you didn't know.) Or maybe allow any string as a timezone by default. If all your times use the same TZ, that's fine; but as soon as you try to work with two times with different zones, you'll get an error, unless you're using a module that knows how to convert between those zones. (While we're at it, why is time zone still officially two words? Usually I like to side with the dictionary, but I can't figure out how timezone has escaped becoming de facto standard English.) ((I also prefer Instant to DateTime unless we end up using both, as in Darren Duncan's suggestion.)) -David
