Re: r25445 - docs/Perl6/Spec/S32-setting-library

2009-02-23 Thread Darren Duncan

Larry Wall wrote:

On Fri, Feb 20, 2009 at 03:31:03PM -0300, Daniel Ruoso wrote:
: Em Sex, 2009-02-20 às 10:17 -0800, Larry Wall escreveu:
:  By the by, I'm also inclined to agree with those who prefer Instant
:  to DateTime on aesthetic grounds.


Yay, I consider that a blessing.

Also yay on your war-pathing against integer fraction of seconds units, another 
blessing.



: I should note that I'm insisting on DateTime just as the reference p5
: module in CPAN, I don't oppose it being called Instant in Perl 6.

And I should clarify that by Instant I was referring to a particular
data type, not the module that defines it.


And I was meaning the same.


I suppose Temporal is as good a module name as any, though Temporal::Instant
does seem a bit redundant...

On the other hand, Instant::Duration is just wrong.


Well, yes.  Instant means a point in time and Duration means an amount of time.

I think Instant and Duration should be the type/role names and Temporal should 
be the name of the module declaring them.


  Perhaps we could

just go with Instant and Duration as top-level roles since they're
rather fundamental to lots of computing.


Do you mean top level as in not existing under some declaring module, or as in 
being imported into the main name-space by default?


  As builtins they would

presumably come with appropriate operators predefined.  And as roles
they could be tweaked by a derived class to mean something slightly
different, if the need arises.


Sounds good to me.

One remaining issue though (perhaps already resolved in an email I didn't read 
yet) is whether these default builtins would be defined in terms of seconds 
since an epoch or in terms of a calendar with YMDHIS (the seconds being a 
non-integer) etc.  I'm inclined to prefer the latter since that is more 
future-proofed (a specified date+time that is in the future won't change on you 
between storage and retrieval with persistent memory).


-- Darren Duncan


Re: Perl's internal time (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)

2009-02-22 Thread Chris Dolan

On Feb 22, 2009, at 12:39 AM, Brandon S. Allbery KF8NH wrote:


On 2009 Feb 20, at 14:36, Chris Dolan wrote:
UTC: TAI with an offset, as corrected for the actual revolution  
of the
Earth: usually 60 seconds in a minute, but occasionally 59 or  
61.  60

minutes in every hour (so 3599, 3600, or 3601 seconds), 24 hours in
every day (86399, 86400, or 86401 seconds).


Yes, just as I said: a constant offset between each of the proposed


Read again; a leap second was added at the end of last year, that's  
not exactly constant.


You missed the trivial point I was trying to make: the number of  
seconds between January 1, 1970 UTC (aka time_t epoch) and January 1,  
2000 TAI *epochs* is a constant.  I did not claim that the time  
systems differed by a constant.  An epoch is an instant in time from  
which other times are measured, so you can measure UTC time flowing  
from a TAI epoch and vice versa.


Astronomers do this all the time to avoid the complexity that the  
Earth's rotation precesses, so the time to orbit the Sun once it not  
exactly the same as a solar year.  Astrometric coordinates are thus  
claimed relative to an epoch, say B1950 or J2000, and can be easily  
transformed between epochs.


Nevertheless, Larry has closed the issue declaring that Perl 6 will  
use TAI, and I'm cool with that.  With just 30-odd lossy exceptions  
in the last 40 years, we can translate between TAI and time_t as  
needed. When the OSes catch up and stop using time_t, it will be a  
glorious day.


... unless we decide to use Stardates instead.  Floating point time  
would be cooler. :-)


Chris


Re: Perl's internal time (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)

2009-02-22 Thread Doug McNutt

At 11:42 -0600 2/22/09, Chris Dolan wrote:

 Floating point time  would be cooler. :-)


And it has been in use by Microsoft in the Excel spreadsheet since 
the Apple Plus which didn't have floating point hardware. But then 
Excel uses the day as the unit. the second would be better.


Re: Temporal changes (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)

2009-02-22 Thread Martin D Kealey
On Fri, 20 Feb 2009, Dave Rolsky wrote:
   Renamed Temporal::Instant to Temporal::DateTime
 
  Hmm.  We had some mailing list discussion about this, and agreed on
  Instant.  I'd like to see your reasons in favour of DateTime.

 Because DateTime makes sense and is a clear description of what the thing
 is. Instant is incredibly ambiguous, and not a common term for such
 things.

I think people are starting to argue at cross purposes here.

An instant and a date-time are NOT the same thing.

Barring limitations imposed by the speed of light and aberrations caused by
relativity, and an instant occurs everyone at the same time.

A date-time, if it's really true to its name, represents some 40-ish
different instants, depending on which timezone it's interpreted in.


At some point you have to decide which fictions are useful vs where you
really need to hold out for reality.

* First fiction: the speed of light is infinite, so instants really are
universal. Unless you're writing GPS control software, you're probably OK
with this.

* Second fiction: the earth rotates at exactly 1/1440 rpm, so UT1=UT.
POSIX's epoch seconds pretty much enforce belief in this, so if you don't
want to believe it, you're going to have to build your own time libraries
from scratch.

* Third fiction: the day matches the rotation of the earth. In some places
the law requires you both to believe and disbelieve this simultaneously.
(For example, it may require that you're billed 10 minutes for a phone call
that started at 01:55 and finished at 03:05.)

* Fourth fiction: it's legally the same time everywhere on earth, especially
for registration of births, deaths and marriages. (For example, if I move
from my native New Zealand to, Hawaii, I will 23 hours older at my next
legal birthday than I would be if I remained in NZ. Probably I'd be a day
younger when I die too.)

* Fifth fiction: everyone speaks English.


It seems there is scope for multiple types, starting with Instants (which
must believe fiction 1 and may or may not believe fiction 2), DateTime
(which is agnostic about fiction 3), and Localtime and Date (which
believe fictions 3 and 4).

For each of these you have corresponding variants of Duration.

So my question is, which of these fictions should the core temporal type(s)
believe or disbelieve? Then we should name them appropriately.

-Martin

PS: IMHO core types should believe 1  2, and disbelieve 3  4, and avoid
doing anything that depends on believing 5.


Re: Temporal changes (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)

2009-02-22 Thread Timothy S. Nelson

On Fri, 20 Feb 2009, Dave Rolsky wrote:


On Fri, 20 Feb 2009, Timothy S. Nelson wrote:


Format specifiers - this could come from locales (CLDR specifies this)
or strftime, but again, it's more complicated than is needed

[snip]

Added iso8601 output for every role, and made that the
stringification. ISO8601 is unambiguous world-wide, easy to read, and
easy to output.


	I'm quite keen to have something here as a formatter.  I was hoping 
for CLDR, but I'd be happy with even a subset of CLDR that does what we 
want. Or even, failing that, with the ISO8601 part being implemented as a 
formatter.


I really don't think this is a good idea. CLDR is complicated _and_ likely to 
change in the future, as it's defined by a spec which we do not control.


It's also entirely oriented around locales, so to do it even vaguely properly


Ok, I was unaware of these bits of information; request withdrawn.


+# These always return the long English names
+method month-name () returns Str; # January
+method day-name () returns Str;   # Tuesday


	This is one reason I was wanting a formatter -- then we wouldn't need 
all these functions.  People could just go $time.format('') and get 
what they want.  Like I said though, the core might be better off with a 
subset of CLDR that does month name, day name, and the ISO8601 
stringification.


I like those methods because they're fluent and easy to read. I think forcing 
people to use a formatter for common, trivial cases is gross.


OTOH, I think the name returning methods could be dropped from core entirely.


Fine by me :).


DateTime math
=


removed all references to ...

[snip]

Any sort of date or time math

[snip]

Got rid of all mutating operators on everything. The built-ins should
be immutable for simplicity.


	Date/time math was something else I'm also very keen to have.  The 
other built-ins play happily with operators -- why wouldn't the temporal 
ones? By mutating operators, do you mean multi operators?  If so, I 
urge you to:


No, by mutating I mean anything which changes the object. As I said, I think 
it's best that the built-ins be immutable.


	Ok, I understand what you're saying now.  Not sure I agree, but I 
doubt others agree with me, so I won't bother arguing :).



Renamed Temporal::Instant to Temporal::DateTime


	Hmm.  We had some mailing list discussion about this, and agreed on 
Instant.  I'd like to see your reasons in favour of DateTime.


Because DateTime makes sense and is a clear description of what the thing is. 
Instant is incredibly ambiguous, and not a common term for such things.


	Hmm.  Ah, I can see why it's ambiguous.  For those who missed it, 
think of what instant means in the context of Instant coffee.  I think I 
still slightly prefer instant, but I don't mind much any more :).



Added numification overloading for Temporal::DateTime, which gives us
comparison for free.


Cool :).

	In case I didn't say this elsewhere, I'd be happy to see localtime 
and gmtime disappear in favour of other temporal constructors.  And surely 
time() could be merged in as well?


I'm sure there could be one constructor as a language built-in, time being a 
reasonable candidate. But I can also see the value of having two, one for UTC 
and one for local time.


	Oh, I agree on retaining the functionality, I just don't think we need 
them as separate functions (ie. ones listed in the revised S29).



-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am   |
-

BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- 
PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y-

-END GEEK CODE BLOCK-



Re: Temporal changes (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)

2009-02-22 Thread Martin D Kealey
On Mon, 23 Feb 2009, Timothy S. Nelson wrote:
Renamed Temporal::Instant to Temporal::DateTime
  
 Hmm.  We had some mailing list discussion about this, and agreed on
   Instant.  I'd like to see your reasons in favour of DateTime.
 
  Because DateTime makes sense and is a clear description of what the thing
  is. Instant is incredibly ambiguous, and not a common term for such things.

 Hmm.  Ah, I can see why it's ambiguous.  For those who missed it, think of
 what instant means in the context of Instant coffee.  I think I still
 slightly prefer instant, but I don't mind much any more :).

Ah, we want a noun that isn't readily confused as an adjective.

Suitable terms might include: Instant Jiffy Juncture Moment Occasion Snap Tick 
...

-Martin


Re: Temporal changes (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)

2009-02-22 Thread Timothy S. Nelson

On Mon, 23 Feb 2009, Martin D Kealey wrote:


On Mon, 23 Feb 2009, Timothy S. Nelson wrote:

Renamed Temporal::Instant to Temporal::DateTime


Hmm.  We had some mailing list discussion about this, and agreed on
Instant.  I'd like to see your reasons in favour of DateTime.


Because DateTime makes sense and is a clear description of what the thing
is. Instant is incredibly ambiguous, and not a common term for such things.


Hmm.  Ah, I can see why it's ambiguous.  For those who missed it, think of
what instant means in the context of Instant coffee.  I think I still
slightly prefer instant, but I don't mind much any more :).


Ah, we want a noun that isn't readily confused as an adjective.

Suitable terms might include: Instant Jiffy Juncture Moment Occasion Snap Tick 
...


	The originator of Instant rejected Moment on the basis that in 
physics, it's used in a variety of ways such as moment of inertia, etc.  My 
personal feeling is that Occasion has other connotations we don't want.


	Anyway, $Larry has decreed that it be Instant, unless you've given him 
an idea above.  I like jiffy, myself, but Wikipedia says In computing, a 
jiffy is the duration of one tick of the system timer interrupt.  If we take 
that as gospel, we probably want to avoid it.  I'd also avoid calling 
something Snap unless it breaks :).  Tick has similar problems to Jiffy.  I 
don't know anything about Junctures, except that the potential for confusion 
with the Perl6 feature Junction is huge.


IOW, none of them are perfect :).


-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am   |
-

BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- 
PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y-

-END GEEK CODE BLOCK-



Re: r25445 - docs/Perl6/Spec/S32-setting-library

2009-02-21 Thread David Green

On 2009-Feb-20, at 11:17 am, Larry Wall wrote:

Certainly, we'll be depending on the type system to keep these things
straight.  I'm not suggesting the user use bare Nums as anything other
than naive durations for APIs such as sleep().


If we have some units to make suitable objects, we can say  
sleep(5`min), etc.  That would mean we can always take time-types, and  
avoid the $t*1000*60*60*24 idiom to boot.


[...]I suppose Temporal is as good a module name as any, though  
Temporal::Instant

does seem a bit redundant...


Well, it distinguishes it from Coffee::Instant...


-David



Re: r25445 - docs/Perl6/Spec/S32-setting-library

2009-02-21 Thread Brandon S. Allbery KF8NH

On 2009 Feb 20, at 12:21, Daniel Ruoso wrote:

Em Sex, 2009-02-20 às 10:40 -0600, Dave Rolsky escreveu:

On Fri, 20 Feb 2009, Daniel Ruoso wrote:

If we're going to use an epoch, it should be the Operating System's
epoch. Anything else will lead to confusion and disorder ;P

And which OS epoch would that be?


The one where the program is being run.

The only way of being actually cross platform is to providing more
semantics to the value, choosing an arbitrary epoch that is not  
going to

be consistent with the epoch used in the OS is simply being annoying.



Strongly disagree:  Perl6 is a high level language; it should not  
force me to operate at a level where the OS's version of time is  
visible, but should always present a higher level abstraction.  I  
should *never* have to work with a time_t unless there is some  
particular reason I need it (e.g. some network protocol or binary file  
format demands it), then there can be an FFI call from a library to  
obtain it or generate a Perl6 time from it.


Quite frankly I won't miss time_t.

--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon universityKF8NH




PGP.sig
Description: This is a digitally signed message part


Re: Perl's internal time (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)

2009-02-21 Thread Brandon S. Allbery KF8NH

On 2009 Feb 20, at 14:36, Chris Dolan wrote:
UTC: TAI with an offset, as corrected for the actual revolution of  
the

Earth: usually 60 seconds in a minute, but occasionally 59 or 61.  60
minutes in every hour (so 3599, 3600, or 3601 seconds), 24 hours in
every day (86399, 86400, or 86401 seconds).


Yes, just as I said: a constant offset between each of the proposed


Read again; a leap second was added at the end of last year, that's  
not exactly constant.


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon universityKF8NH




PGP.sig
Description: This is a digitally signed message part


Re: Temporal changes (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)

2009-02-20 Thread Dave Rolsky

On Fri, 20 Feb 2009, Timothy S. Nelson wrote:


Format specifiers - this could come from locales (CLDR specifies this)
or strftime, but again, it's more complicated than is needed

[snip]

Added iso8601 output for every role, and made that the
stringification. ISO8601 is unambiguous world-wide, easy to read, and
easy to output.


	I'm quite keen to have something here as a formatter.  I was hoping 
for CLDR, but I'd be happy with even a subset of CLDR that does what we want. 
Or even, failing that, with the ISO8601 part being implemented as a 
formatter.


I really don't think this is a good idea. CLDR is complicated _and_ likely 
to change in the future, as it's defined by a spec which we do not 
control.


It's also entirely oriented around locales, so to do it even vaguely 
properly we'd have to at least include a locale, and which one would that 
be? en-US?


Again, locales are complicated and subject to change.

If there _must_ be a formatter (which I don't think is necessary), I'd 
suggest it be based on the Unix strftime. Except that still has some 
locale-specific bits. However, generally you can get the system itself to 
implement this for you.



+# These always return the long English names
+method month-name () returns Str; # January
+method day-name () returns Str;   # Tuesday


	This is one reason I was wanting a formatter -- then we wouldn't need 
all these functions.  People could just go $time.format('') and get what 
they want.  Like I said though, the core might be better off with a subset of 
CLDR that does month name, day name, and the ISO8601 stringification.


I like those methods because they're fluent and easy to read. I think 
forcing people to use a formatter for common, trivial cases is gross.


OTOH, I think the name returning methods could be dropped from core 
entirely.



DateTime math
=


removed all references to ...

[snip]

Any sort of date or time math

[snip]

Got rid of all mutating operators on everything. The built-ins should
be immutable for simplicity.


	Date/time math was something else I'm also very keen to have.  The 
other built-ins play happily with operators -- why wouldn't the temporal 
ones? By mutating operators, do you mean multi operators?  If so, I urge 
you to:


No, by mutating I mean anything which changes the object. As I said, I 
think it's best that the built-ins be immutable.



Renamed Temporal::Instant to Temporal::DateTime


	Hmm.  We had some mailing list discussion about this, and agreed on 
Instant.  I'd like to see your reasons in favour of DateTime.


Because DateTime makes sense and is a clear description of what the thing 
is. Instant is incredibly ambiguous, and not a common term for such 
things.


	One of my (unmentioned) reasons for not calling it DateTime is that I 
was expecting the CPAN module to be called DateTime, and didn't want to stamp 
on any names.  But that's not as high a priority.


But this is a bunch of roles. If I upload something called just DateTime 
to CPAN6, it better do this role, right? That's part of the reason I'm 
trying to keep things really simple.



Added numification overloading for Temporal::DateTime, which gives us
comparison for free.


Cool :).

	In case I didn't say this elsewhere, I'd be happy to see localtime 
and gmtime disappear in favour of other temporal constructors.  And surely 
time() could be merged in as well?


I'm sure there could be one constructor as a language built-in, time being 
a reasonable candidate. But I can also see the value of having two, one 
for UTC and one for local time.



-dave

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


Re: r25445 - docs/Perl6/Spec/S32-setting-library

2009-02-20 Thread Dave Rolsky

On Thu, 19 Feb 2009, Larry Wall wrote:


Is there a way in which a class which does the Date role could change the
type $.year so it was Int|Undef?


Doesn't have to.  Int already comes with an undefined value known as
Int, aka the protoobject.  Only subset types (and their cousins, native
types) can restrict values to being defined, and they do so on the
primarily on basis of constraints, and only secondarily on whether the
underlying storage can represent an undefined value.   So an Int can be
undefined, but an int can't.  A Num can be undefined, but a num can only
approximate that with NaN.


Well, if you look at the spec I _did_ create subsets for most of those 
values like this:


  my subset Hour   of Int where { 0 = $^a = 23 };


That being said, I'm thinking that all actual times represented by
floats in Perl are TAI time, not the Unix pseudo time with hidden
leap seconds.  I sure wish they'd done away with civic leap seconds
in 2000 and said we'll put in a leap minute or two on century breaks...


That's certainly fine with me, but I think we'd still want some simple 
objects on top of them, rather than handing people a single epoch numbre 
to deal with.



-dave

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


Re: r25445 - docs/Perl6/Spec/S32-setting-library

2009-02-20 Thread Daniel Ruoso
Em Qui, 2009-02-19 às 15:58 -0800, Larry Wall escreveu:
 That being said, I'm thinking that all actual times represented by
 floats in Perl are TAI time, not the Unix pseudo time with hidden
 leap seconds.  I sure wish they'd done away with civic leap seconds
 in 2000 and said we'll put in a leap minute or two on century breaks...

I beg to disagree.

If we're going to use an epoch, it should be the Operating System's
epoch. Anything else will lead to confusion and disorder ;P

OTOH, what has been argued here (and I agree) is that epoch doesn't
provide semantics that *were supposed to be taken into account* in most
operations.

For instance, if you want to add 1 day using an epoch, you'd think
that adding 86400 seconds should do the trick, but that only works if
you're not planning any conversions between timezones, because there are
days with 23 and days with 25 hours. I once fixed a code like the
following.

my $reference = time;
my $month = (localtime($now))[4];
while ((localtime($now))[4] == $month) { $reference += 86400 };

The only viable solution is to use a module that provides the proper
semantics (and I insisit that DateTime is that module, currently).

The above operation is far from being an exotic operation. That kind of
thing is indeed very common. 

The argument in this thread is exactly about making the basic operations
that involve time (time, localtime, gmtime, stat) to return a DateTime
object that implements all the semantics involved in DateTime
operations. IMNSHO, the DateTime module in CPAN is the reference to be
used in that matter.

daniel



Re: r25445 - docs/Perl6/Spec/S32-setting-library

2009-02-20 Thread Dave Rolsky

On Fri, 20 Feb 2009, Daniel Ruoso wrote:


Em Qui, 2009-02-19 às 15:58 -0800, Larry Wall escreveu:

That being said, I'm thinking that all actual times represented by
floats in Perl are TAI time, not the Unix pseudo time with hidden
leap seconds.  I sure wish they'd done away with civic leap seconds
in 2000 and said we'll put in a leap minute or two on century breaks...


I beg to disagree.

If we're going to use an epoch, it should be the Operating System's
epoch. Anything else will lead to confusion and disorder ;P


And which OS epoch would that be?

See http://en.wikipedia.org/wiki/Epoch_(reference_date)#Computing

I don't care what epoch we standardize on, as long as it's consistent 
across platforms.



-dave

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

Re: Perl's internal time (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)

2009-02-20 Thread Mark J. Reed
Considering time scales, there are three that significantly
interrelate, and no matter what Perl 6 uses internally, it needs to be
able to convert to and from these:

TAI: continuous count of time using SI seconds as measured by atomic
clocks, 60 seconds in every minute, 60 minutes in every hour, 24 hours
in every day.

UTC: TAI with an offset, as corrected for the actual revolution of the
Earth: usually 60 seconds in a minute, but occasionally 59 or 61.  60
minutes in every hour (so 3599, 3600, or 3601 seconds), 24 hours in
every day (86399, 86400, or 86401 seconds).

time_t: the value you get by taking the UTC time since Jan 1, 1970 at
midnight and converting to a simple count of seconds, pretending there
have been no leap seconds along the way.

Right now as I type this it is 17:13:38 UTC.   That's 17:14:12 in TAI
(which is 34 seconds ahead of UTC until the next leap second).  The
corresponding time_t value is 1,235,150,018, but there have actually
been 1,235,150,042 seconds since the UNIX epoch.


Re: r25445 - docs/Perl6/Spec/S32-setting-library

2009-02-20 Thread Daniel Ruoso
Em Sex, 2009-02-20 às 10:40 -0600, Dave Rolsky escreveu:
 On Fri, 20 Feb 2009, Daniel Ruoso wrote:
  If we're going to use an epoch, it should be the Operating System's
  epoch. Anything else will lead to confusion and disorder ;P
 And which OS epoch would that be?

The one where the program is being run.

The only way of being actually cross platform is to providing more
semantics to the value, choosing an arbitrary epoch that is not going to
be consistent with the epoch used in the OS is simply being annoying.

daniel



Re: r25445 - docs/Perl6/Spec/S32-setting-library

2009-02-20 Thread Larry Wall
On Fri, Feb 20, 2009 at 02:21:50PM -0300, Daniel Ruoso wrote:
: Em Sex, 2009-02-20 às 10:40 -0600, Dave Rolsky escreveu:
:  On Fri, 20 Feb 2009, Daniel Ruoso wrote:
:   If we're going to use an epoch, it should be the Operating System's
:   epoch. Anything else will lead to confusion and disorder ;P
:  And which OS epoch would that be?
: 
: The one where the program is being run.
: 
: The only way of being actually cross platform is to providing more
: semantics to the value, choosing an arbitrary epoch that is not going to
: be consistent with the epoch used in the OS is simply being annoying.

Perl 6 will have a type system, unlike C.

Larry


Re: r25445 - docs/Perl6/Spec/S32-setting-library

2009-02-20 Thread Larry Wall
On Fri, Feb 20, 2009 at 08:12:36AM -0600, Dave Rolsky wrote:
 That's certainly fine with me, but I think we'd still want some simple  
 objects on top of them, rather than handing people a single epoch numbre  
 to deal with.

Certainly, we'll be depending on the type system to keep these things
straight.  I'm not suggesting the user use bare Nums as anything other
than naive durations for APIs such as sleep().  I'm more interested
in the mathematical purity (counting floating point as pure *cough*)
of the operations, and the proper use of the type system to keep the
units straight.  I'm also interested in killing the POSIX concept of
time as soon as possible, at least as the default view of reality.

By the by, I'm also inclined to agree with those who prefer Instant
to DateTime on aesthetic grounds.

Larry


Re: r25445 - docs/Perl6/Spec/S32-setting-library

2009-02-20 Thread Daniel Ruoso
Em Sex, 2009-02-20 às 10:17 -0800, Larry Wall escreveu:
 By the by, I'm also inclined to agree with those who prefer Instant
 to DateTime on aesthetic grounds.

I should note that I'm insisting on DateTime just as the reference p5
module in CPAN, I don't oppose it being called Instant in Perl 6.

daniel



Re: r25445 - docs/Perl6/Spec/S32-setting-library

2009-02-20 Thread Larry Wall
On Fri, Feb 20, 2009 at 03:31:03PM -0300, Daniel Ruoso wrote:
: Em Sex, 2009-02-20 às 10:17 -0800, Larry Wall escreveu:
:  By the by, I'm also inclined to agree with those who prefer Instant
:  to DateTime on aesthetic grounds.
: 
: I should note that I'm insisting on DateTime just as the reference p5
: module in CPAN, I don't oppose it being called Instant in Perl 6.

And I should clarify that by Instant I was referring to a particular
data type, not the module that defines it.

I suppose Temporal is as good a module name as any, though Temporal::Instant
does seem a bit redundant...

On the other hand, Instant::Duration is just wrong.  Perhaps we could
just go with Instant and Duration as top-level roles since they're
rather fundamental to lots of computing.  As builtins they would
presumably come with appropriate operators predefined.  And as roles
they could be tweaked by a derived class to mean something slightly
different, if the need arises.

Larry


Re: r25445 - docs/Perl6/Spec/S32-setting-library

2009-02-20 Thread Daniel Ruoso
Em Sex, 2009-02-20 às 10:53 -0800, Larry Wall escreveu:
 Perhaps we could just go with Instant and Duration as top-level roles
 since they're rather fundamental to lots of computing.  As builtins
 they would presumably come with appropriate operators predefined.  And
 as roles they could be tweaked by a derived class to mean something
 slightly different, if the need arises.

That's exactly the kind of solution I was hoping for ;)

We still will need to think on the API to that, and that's where looking
at p5 DateTime makes sense ;)

daniel



Re: Perl's internal time (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)

2009-02-20 Thread Larry Wall
On Fri, Feb 20, 2009 at 01:36:12PM -0600, Chris Dolan wrote:
: Yes, just as I said: a constant offset between each of the proposed
: epochs.  But my point remains: from the user's point of view it doesn't
: matter which epoch you choose to use behind the scenes, so you might as
: well pick the one that's easiest on the software (time_t) and leave the
: transformations to the libraries.

time_t must die.  This is non-negotiable.

Larry


Re: Perl's internal time (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)

2009-02-20 Thread Mark J. Reed
On Fri, Feb 20, 2009 at 2:36 PM, Chris Dolan ch...@chrisdolan.net wrote:
 Yes, just as I said: a constant offset between each of the proposed
 epochs.

No, because the offset is not constant.  The delta between TAI and UTC
is currently 34 seconds.  Two months ago it was 33 seconds.  The next
time there's a leap second it will change again.  And we can't
reliably predict when that will be.

time_t is indeed easiest to implement, but it doesn't have any way of
distinguishing 2008-12-31 23:59:60 UTC from 2009-01-01 00:00:00 UTC.
Better to use a basis that has all the information and then transform
the value into the lossier form on demand, I think.


Re: r25445 - docs/Perl6/Spec/S32-setting-library

2009-02-19 Thread Dave Rolsky

On Thu, 19 Feb 2009, Darren Duncan wrote:


As per my previous post, I recommend having both, like this:

 role Instant {
   has Int $.year;
   ...
   has Rat $.second;
 }

 role DateTime is Instant where defined $.year ... and defined $.second;

 role Date is Instant where defined $.year ... and defined $.day;

 role Time is Instant where defined $.hour ... and defined $.second;

So something like that.  So Date and Time mean all Date|Time details, and 
DateTime means all details of both.  And Instant means any combination of 
defined or not of said member attributes.  And that's actually why I 
advocated Instant as a name for that more-broad-than-DateTime thing.


Is there a way in which a class which does the Date role could change the 
type $.year so it was Int|Undef?


I'd prefer to leave the notion of an incomplete Date(|Time|DateTime) out 
of the core, because it makes everything more complicated.


If, OTOH, I couldn't make OnCPAN6::DateTime::Incomplete do the DateTime 
interface, that'd be a good argument for changing the core interface.



-dave

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


Re: r25445 - docs/Perl6/Spec/S32-setting-library

2009-02-19 Thread Darren Duncan

Dave Rolsky wrote:

On Thu, 19 Feb 2009, Darren Duncan wrote:
So something like that.  So Date and Time mean all Date|Time details, 
and DateTime means all details of both.  And Instant means any 
combination of defined or not of said member attributes.  And that's 
actually why I advocated Instant as a name for that 
more-broad-than-DateTime thing.


Is there a way in which a class which does the Date role could change 
the type $.year so it was Int|Undef?


I'd prefer to leave the notion of an incomplete Date(|Time|DateTime) out 
of the core, because it makes everything more complicated.


If, OTOH, I couldn't make OnCPAN6::DateTime::Incomplete do the DateTime 
interface, that'd be a good argument for changing the core interface.


I was under the impression that Perl typed containers are allowed to hold Undef 
by default, eg when you say has Int $foo that allows an Undef $foo by default. 
 So in that case I'm already getting what flexibility I want by default if that 
is how the roles are declared.  Correct me if I'm wrong. -- Darren Duncan


Re: r25445 - docs/Perl6/Spec/S32-setting-library

2009-02-19 Thread Larry Wall
On Thu, Feb 19, 2009 at 05:05:32PM -0600, Dave Rolsky wrote:
 On Thu, 19 Feb 2009, Darren Duncan wrote:

 As per my previous post, I recommend having both, like this:

  role Instant {
has Int $.year;
...
has Rat $.second;
  }

  role DateTime is Instant where defined $.year ... and defined $.second;

  role Date is Instant where defined $.year ... and defined $.day;

  role Time is Instant where defined $.hour ... and defined $.second;

 So something like that.  So Date and Time mean all Date|Time details, 
 and DateTime means all details of both.  And Instant means any 
 combination of defined or not of said member attributes.  And that's 
 actually why I advocated Instant as a name for that 
 more-broad-than-DateTime thing.

 Is there a way in which a class which does the Date role could change the 
 type $.year so it was Int|Undef?

Doesn't have to.  Int already comes with an undefined value known as
Int, aka the protoobject.  Only subset types (and their cousins, native
types) can restrict values to being defined, and they do so on the
primarily on basis of constraints, and only secondarily on whether the
underlying storage can represent an undefined value.   So an Int can be
undefined, but an int can't.  A Num can be undefined, but a num can only
approximate that with NaN.

So the built-in types may certainly represent incomplete information.

That being said, I'm thinking that all actual times represented by
floats in Perl are TAI time, not the Unix pseudo time with hidden
leap seconds.  I sure wish they'd done away with civic leap seconds
in 2000 and said we'll put in a leap minute or two on century breaks...

Well, leaving that rant aside, I'm still tempted to say that times
in Perl 6 are TAI seconds since 2000.  Standard TAI would work too.
In any case, I think if Perl is to be taken seriously for scientific
computing its native seconds shouldn't be varying in length.  And I
also think with the advent of ubiquitous GPS we're getting to the
point where nearly all computers will know the correct atomic time.
Time is on our side, as it were...

Larry


Temporal changes (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)

2009-02-19 Thread Timothy S. Nelson

On Thu, 19 Feb 2009, pugs-comm...@feather.perl6.nl wrote:


Author: autarch
Date: 2009-02-19 19:14:48 +0100 (Thu, 19 Feb 2009)
New Revision: 25445

Modified:
  docs/Perl6/Spec/S32-setting-library/Temporal.pod
Log:
This is a very drastic revision (hopefully this won't turn into a revert war ;)


	I hope not.  My plan is to argue about them on the mailing list, and 
hope that we'll come to some reasonable consensus :).


	I'd also like to say a mea culpa -- I had a commit ready to go before 
I asked Dave/autarch to make the appropriate changes, but I forgot to commit 
it :).  So some of the stupid things are things I should've done myself.


	I've noticed that a number of my objections were scattered various 
places throughout my reply, so I'm taking the liberty of grouping a few things 
together by argument :).


Formatters
==


removed all references to ...

[snip]

Format specifiers - this could come from locales (CLDR specifies this)
or strftime, but again, it's more complicated than is needed

[snip]

Added iso8601 output for every role, and made that the
stringification. ISO8601 is unambiguous world-wide, easy to read, and
easy to output.


	I'm quite keen to have something here as a formatter.  I was hoping 
for CLDR, but I'd be happy with even a subset of CLDR that does what we want. 
Or even, failing that, with the ISO8601 part being implemented as a formatter.



+# These always return the long English names
+method month-name () returns Str; # January
+method day-name () returns Str;   # Tuesday


	This is one reason I was wanting a formatter -- then we wouldn't need 
all these functions.  People could just go $time.format('') and get what 
they want.  Like I said though, the core might be better off with a subset of 
CLDR that does month name, day name, and the ISO8601 stringification.



+# returns the date formatted in ISO8601 style - 2008-01-25
+   method iso8601 () returns Str
+{ [ self.year, self.month, self.date ].join('-') };


	I was hoping we could leave this also to a formatter that would be 
called upon by infix:{'~'}.



DateTime math
=


removed all references to ...

[snip]

Any sort of date or time math

[snip]

Got rid of all mutating operators on everything. The built-ins should
be immutable for simplicity.


	Date/time math was something else I'm also very keen to have.  The 
other built-ins play happily with operators -- why wouldn't the temporal ones? 
By mutating operators, do you mean multi operators?  If so, I urge you to:

-   Read my comments lower down in this e-mail about the infix:~
operator, which will give you some appropriate background
-   See http://perlcabal.org/syn/S03.html#Smart_matching which appears to
me to make the ~~ operator do all kinds of things (although I could be
wrong here).  Actually, the point I'm making is much more easily seen
by finding =head1 Smart matching in
http://svn.pugscode.org/pugs/docs/Perl6/Spec/S03-operators.pod

Other things



Here's the changes in summary:

removed all references to ...

Locales, including eras, which come from a locale - this is a vast and 
complicated domain

Alternate calendars - also vast and complicated

String parsing of any sort - ditto, see the pattern here? ;)

Comparing dates or times to durations - this just doesn't make
sense. Is 2009-02-23 greater or less than 5 days?


I agree, this was stupid :).


Renamed Temporal::Instant to Temporal::DateTime


	Hmm.  We had some mailing list discussion about this, and agreed on 
Instant.  I'd like to see your reasons in favour of DateTime.


	One of my (unmentioned) reasons for not calling it DateTime is that I 
was expecting the CPAN module to be called DateTime, and didn't want to stamp 
on any names.  But that's not as high a priority.



Got rid of Temporal::Subsecond and just made Temporal::Time allow for
sub-second resolutions. Not sure if this is best done with an
$.attosecond attribute or as a decimal number.


See other discussions on the mailing list.


Renamed Temporal::Timezone to Temporal::TimeZone::Observance. The
latter is a simple thing which represents the offset, isdst flag, and
short name for a given local time. This information should be
available on all supported platforms. TimeZones themselves are
complicated and very much platform-dependent. Better to leave this as
a separate CPAN6 distro.


	Bewdy mate!  :)  [to translate that into non-Australian, it's 
Beauty, mate, or I'm pleased, friend].



Added numification overloading for Temporal::DateTime, which gives us
comparison for free.


Cool :).

	In case I didn't say this elsewhere, I'd be happy to see localtime and 
gmtime disappear in favour of other temporal constructors.  And surely time() 
could be merged in as well?



+method infix:{'~'} return Str { self.iso8601 };


	Also, while I may be wrong, my reading of S13 says 

Perl's internal time (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)

2009-02-19 Thread Timothy S. Nelson

On Thu, 19 Feb 2009, Larry Wall wrote:


Well, leaving that rant aside, I'm still tempted to say that times
in Perl 6 are TAI seconds since 2000.  Standard TAI would work too.


	I've wondered sometimes about the idea of having a dual/moving epoch. 
By this, I mean that you have eg. two Ints, one which represents the years 
since 1AD or whatever, and the other of which represents the number of seconds 
from the beginning of that year.  I'm sure many of you can see the advantages 
and disadvantages of that scheme better than I can, but I thought I'd throw it 
out there so you can all see whether or not you like it.



-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am   |
-

BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- 
PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y-

-END GEEK CODE BLOCK-



Re: Perl's internal time (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)

2009-02-19 Thread Chris Dolan

On Feb 19, 2009, at 10:17 PM, Timothy S. Nelson wrote:


On Thu, 19 Feb 2009, Larry Wall wrote:


Well, leaving that rant aside, I'm still tempted to say that times
in Perl 6 are TAI seconds since 2000.  Standard TAI would work too.


	I've wondered sometimes about the idea of having a dual/moving  
epoch. By this, I mean that you have eg. two Ints, one which  
represents the years since 1AD or whatever, and the other of which  
represents the number of seconds from the beginning of that year.   
I'm sure many of you can see the advantages and disadvantages of  
that scheme better than I can, but I thought I'd throw it out there  
so you can all see whether or not you like it.




I don't see the advantage of either of those.  TAI 2000 is just UTC  
1970 plus a constant offset.  1AD is just UTC 1970 minus a bigger  
constant offset.  Sure, those are slightly easier epochs for a human  
(ignoring the Julian/Gregorian shift), but not any easier for a  
computer.  UTC 1970 has the big advantage that it is already the  
underlying value returned by most operating systems and many date/ 
time libraries, so there's no extra additive operation to perform if  
that's what you want.


A much more important issue is the use of integer seconds.   
Milliseconds is a much more useful precision for humans and micro- or  
nanoseconds is a better precision for machines.  I think Time::HiRes  
with a better API as a builtin would be a big win.


Aside: I just learned the other day that Java's Thread.sleep(long  
millis, int nanos) method just rounds the nanos to the nearest millis  
and invokes Thread.sleep(long millis).  I guess that's a forward  
looking API for when the OS really can timeslice that small, but it's  
a little silly today.
http://krugle.org/kse/entfiles/jdk/sun.com/jdk-1.5/j2se/src/share/ 
classes/java/lang/Thread.java#246


Maybe Perl 6 should be really forward looking and include a time  
dilation factor so it can be the first language designed from the  
ground up for interstellar travelers who want to use a non-inertial  
reference.  Or GPS?  :-)


Chris


Re: Perl's internal time (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)

2009-02-19 Thread Timothy S. Nelson

On Thu, 19 Feb 2009, Chris Dolan wrote:


On Feb 19, 2009, at 10:17 PM, Timothy S. Nelson wrote:


On Thu, 19 Feb 2009, Larry Wall wrote:


Well, leaving that rant aside, I'm still tempted to say that times
in Perl 6 are TAI seconds since 2000.  Standard TAI would work too.


	I've wondered sometimes about the idea of having a dual/moving epoch. 
By this, I mean that you have eg. two Ints, one which represents the years 
since 1AD or whatever, and the other of which represents the number of 
seconds from the beginning of that year.  I'm sure many of you can see the 
advantages and disadvantages of that scheme better than I can, but I 
thought I'd throw it out there so you can all see whether or not you like 
it.




I don't see the advantage of either of those.  TAI 2000 is just UTC 1970 plus 
a constant offset.  1AD is just UTC 1970 minus a bigger constant offset. 
Sure, those are slightly easier epochs for a human (ignoring the 
Julian/Gregorian shift), but not any easier for a computer.  UTC 1970 has the 
big advantage that it is already the underlying value returned by most 
operating systems and many date/time libraries, so there's no extra additive 
operation to perform if that's what you want.


	Having now read the Wikipedia page on time_t, I withdraw my suggestion 
:).



A much more important issue is the use of integer seconds.  Milliseconds is a


	The new interface looks like it will cope with something small fairly 
well.  Dave Rolsky is doing a good job, even though I think there may be room 
for improvement :).


Maybe Perl 6 should be really forward looking and include a time dilation 
factor so it can be the first language designed from the ground up for 
interstellar travelers who want to use a non-inertial reference.  Or GPS?


	I'm not a rocket surgeon, but we'd need a $.velocity to calculate 
that, wouldn't we?


:)


-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am   |
-

BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- 
PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y-

-END GEEK CODE BLOCK-



Re: Temporal changes (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)

2009-02-19 Thread Wayland

On Fri, 20 Feb 2009, Timothy S. Nelson wrote:


+role   Temporal::DateTime {
+has Temporal::Date $!date handles year month day day-of-week;


	Can't do this, I think; this would require an instance of 
Temporal::Date, which is a role and can't be instantiated.  That's why I was 
using does instead.  I don't know what the alternative is, but I'll leave 
that to you :).


Ok, I'm wrong here; sorry :).


-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am   |
-

BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- 
PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y-

-END GEEK CODE BLOCK-