Re: date and time formatting

2005-06-03 Thread Rob Kinyon
 localtime() and gmtime() seem fairly core to me.  The array contexts are
 simple, and the scalar context is an RFC valid string.  Nothing too heavy
 there.  The time() function is typically only moderately useful without
 localtime().

This is true if the time() function returns a simple scalar containing
seconds since the Unix epoch. If, however, it returned a DateTime
object that numified to said value, but provided both localtime() and
gmtime() methods (and a whole lot more) ... wouldn't that be better?

Rob


Re: date and time formatting

2005-06-02 Thread Paul Seamons
 So, if we continue following this API, Perl6 core will contain time(),
 but no localtime() nor gmtime().  The Date module will provide human
 readable date and time strings, and basic date math.

localtime() and gmtime() seem fairly core to me.  The array contexts are 
simple, and the scalar context is an RFC valid string.  Nothing too heavy 
there.  The time() function is typically only moderately useful without 
localtime().

Paul


Re: date and time formatting

2005-06-02 Thread Juerd
Paul Seamons skribis 2005-06-02  9:43 (-0600):
 localtime() and gmtime() seem fairly core to me.  The array contexts are 
 simple, and the scalar context is an RFC valid string.  Nothing too heavy 

s/array context/list context/


Juerd
-- 
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html 
http://convolution.nl/gajigu_juerd_n.html


Re: date and time formatting

2005-06-01 Thread TSa (Thomas Sandlaß)

Sam Vilain wrote:

I also don't like implicit normalisation to seconds
underneath the hood when I'm doing basic date calculations, and
the way that the DateTime base class is inherantly based on the
Gregorian calendar.


I concur in this view. From a typing point of view there should
be some common base type that can handle cross-calender arithmetic
but as long as one stays in a homogenous subtype like Gregorian
in a particular time zone no generalization code should fire up.
--
TSa (Thomas Sandlaß)



Re: date and time formatting

2005-06-01 Thread Nathan Gray
On Wed, Jun 01, 2005 at 03:42:57PM +1200, Sam Vilain wrote:
 I've made a start on this.  See ext/Date in pugs.  I don't think that
 your views are necessarily contrary.

That's what I'm looking for.  Thank you!

 The biggest reason I didn't use DateTime was that I found it awkward
 for the common case; most of the time I just want to stuff in an
 ISO8601 date.  I also don't like implicit normalisation to seconds
 underneath the hood when I'm doing basic date calculations, and
 the way that the DateTime base class is inherantly based on the
 Gregorian calendar.
 
 The Date and Duration roles are extremely minimal; see
 
http://svn.openfoundry.org/pugs/ext/Date/lib/Date.pm
http://svn.openfoundry.org/pugs/ext/Date/lib/Duration.pm
 
 The major API is described at:
 
http://svn.openfoundry.org/pugs/ext/Date/lib/Date/Gregorian.pod
 
 This module is supposed to be somewhere between DateTime and
 Class::Date, with built-in ISO-8601 support (as it's the standard ;)).

So, if we continue following this API, Perl6 core will contain time(),
but no localtime() nor gmtime().  The Date module will provide human
readable date and time strings, and basic date math.

 With a bit of luck, all Date implementation can share this `Date'
 Role, and Gregorian calendar modules share the `Date::Gregorian' Role,
 so that the multitude of implementations that crop up will be mutually
 exchangable, and the simple case fast, efficient and useful.

So further date manipulation could be provided by other date modules,
hopefully within the same framework.

Sounds good to me.

-kolibrie


Re: date and time formatting

2005-05-31 Thread Rob Kinyon
On 5/31/05, Nathan Gray [EMAIL PROTECTED] wrote:
 As I am interested in human-readable dates and times, and having found
 no conclusive discussion on time formatting, I make my recommendation
 for a syntax (to start discussion, and allow for date formatting to be
 implemented in pugs):

What's wrong with porting DateTime?

Rob


Re: date and time formatting

2005-05-31 Thread Patrick R. Michaud
On Tue, May 31, 2005 at 09:23:11AM -0400, Nathan Gray wrote:
 As I am interested in human-readable dates and times, and having found
 no conclusive discussion on time formatting, I make my recommendation
 for a syntax (to start discussion, and allow for date formatting to be
 implemented in pugs):
 
 I would like for time() to return an object, which in numeric context is
 the number of seconds from the epoch (the new epoch, of course), and
 which in string context is a human-readable string.  We could also use
 localtime(), and leave time() alone.

Just a friendly note that since this is a language design issue 
(as opposed to an implementation one) this thread likely belongs 
only on perl6-language and not on perl6-compiler.  I'm just trying
to keep the traffic on the lists at a reasonable volume ... :-)

Followups to p6l, please, unless there's an obvious reason why they
need to be on p6c.

Pm


Re: date and time formatting

2005-05-31 Thread David Storrs


On May 31, 2005, at 9:51 AM, Rob Kinyon wrote:


On 5/31/05, Nathan Gray [EMAIL PROTECTED] wrote:

As I am interested in human-readable dates and times, and having  
found

no conclusive discussion on time formatting, I make my recommendation
for a syntax (to start discussion, and allow for date formatting  
to be

implemented in pugs):



What's wrong with porting DateTime?

Rob



It's back to the old question of what's in core?  Are dates and  
times something that are used in such a large proportion of programs  
that they deserve to be shipped in the basic grammar?  Or perhaps in  
the basic set of packages?


Perl 5 has an entire swath of modules designed to manipulate dates  
and times; this suggests that they are (A) commonly used and (B)  
something that people feel very strongly about the semantics of.



--Dks


Re: date and time formatting

2005-05-31 Thread Rob Kinyon
  What's wrong with porting DateTime?
 
 It's back to the old question of what's in core?  Are dates and
 times something that are used in such a large proportion of programs
 that they deserve to be shipped in the basic grammar?  Or perhaps in
 the basic set of packages?
 
 Perl 5 has an entire swath of modules designed to manipulate dates
 and times; this suggests that they are (A) commonly used and (B)
 something that people feel very strongly about the semantics of.

Which still begs the question - why not port DateTime to P6? Why can't
installing a module provide new keywords?

Rob


Re: date and time formatting

2005-05-31 Thread Rod Adams

Nathan Gray wrote:


possibly as an strftime() pattern.

 



Can we please make sure that strftime() is _not_ OS dependent like the 
POSIX version is now?


-- Rod Adams


Re: date and time formatting

2005-05-31 Thread David Storrs


On May 31, 2005, at 1:16 PM, Rob Kinyon wrote:


What's wrong with porting DateTime?



It's back to the old question of what's in core?  Are dates and
times something that are used in such a large proportion of programs
that they deserve to be shipped in the basic grammar?  Or perhaps in
the basic set of packages?

Perl 5 has an entire swath of modules designed to manipulate dates
and times; this suggests that they are (A) commonly used and (B)
something that people feel very strongly about the semantics of.



Which still begs the question - why not port DateTime to P6? Why can't
installing a module provide new keywords?

Rob



In reverse order:

- No reason it can't.  Nor did I imply otherwise.

- I didn't say we shouldn't port DateTime.  My point was simply that,  
based on the amount of date-related code on CPAN, this is an issue  
that many people care about quite a bit.  We would probably be well  
served to consider it carefully and decide on what semantics we  
really want.  Maybe DateTime is exactly what everyone wants and all  
we need to do is port it.  On the other hand, there is something to  
be said for Nathan's approach; isn't it worth discussing?



Personally, I've always found date handling to be difficult.  The  
various modules go a long way towards simplifying it, but they  
require calling functions and methods, which forces one to think in a  
low-level algorithmic style.   It would be great if there was a more  
intuitive time/date handling model built into the language...the kind  
of quantum leap in power and intuitiveness that we got from the new  
Rules engine (as opposed to the old regex engine).


Perhaps something like the typed operations that were discussed  
recently:


my ($launch_date = now() + 6 weeks) but time(9am);
say We will launch on a $lauch_date.day_of_week, at  
$launch_date.time_of_day.;
say This gives us  . $launch_date but hours .  hours,  
including weekends and evenings.;


#  outstanding_tickets() returns user-written ticket objects;  
created() returns a time object representing

#  creation time.  The objects stringify to their report.
say Remaining issues, oldest first:;
say \t $_ for sort { $a.creation().age = $b.creation().age }  
outstanding_tickets();


#  Prints 'Meetings are...is Sunday, June 19.;
say Meetings are the third Sunday of each month.  The first  
June meeting is  .
(month(6).days(0))[2] but format(/dayname, monthname  
day/);


The above examples are just noodlings and are not well thought out,  
but hopefully they point in the right direction.


--Dks


Re: date and time formatting

2005-05-31 Thread Rob Kinyon
 - I didn't say we shouldn't port DateTime.  My point was simply that,
 based on the amount of date-related code on CPAN, this is an issue
 that many people care about quite a bit.  We would probably be well
 served to consider it carefully and decide on what semantics we
 really want.  Maybe DateTime is exactly what everyone wants and all
 we need to do is port it.  On the other hand, there is something to
 be said for Nathan's approach; isn't it worth discussing?

What I'm trying to get at isn't that DateTime's API should be
preserved. I'm saying that the concept of DateTime should be ported.
Core or not core - it doesn't matter. When use'd (or installed), it
should override now() (and anyone else we can think of) to return an
object that DWIMs, plus provides the interface you've outlined below.

 Perhaps something like the typed operations that were discussed
 recently:
 
  my ($launch_date = now() + 6 weeks) but time(9am);
  say We will launch on a $lauch_date.day_of_week, at
 $launch_date.time_of_day.;
  say This gives us  . $launch_date but hours .  hours,
 including weekends and evenings.;

Sure. $launch_date is of type DateTime. It will numify to the
seconds-since-the-epoch, stringify to some date string, and provide
all the neat-o-keen methods you want it to have.

Frankly, I think we're in violent agreement here. I don't think this
is something that needs to be built into the language. This is
something that should be strongly-recommended for downloading. Kinda
like you always expect DBI to be around when you go to a new major
client, but it's not core.

Well, I always expect DBI to be around ... :-)

Rob


Re: date and time formatting

2005-05-31 Thread David Storrs

On May 31, 2005, at 2:22 PM, Rob Kinyon wrote:

 my ($launch_date = now() + 6 weeks) but time(9am);


Sure. $launch_date is of type DateTime. It will numify to the
seconds-since-the-epoch, stringify to some date string, and provide
all the neat-o-keen methods you want it to have.


Works for me.


Frankly, I think we're in violent agreement here.


Sounds like it.  I don't really care if it's built in or comes in a  
module.  I do think that date manipulation is common enough that, if  
it's in a module, the module should come in the basic set.


I met a guy once who made his living doing Java programming.  I asked  
him what he liked about Java and he said Nothing.  I hate it. I only  
do it because it pays.  He then went on to list the reasons he hated  
it--high on the list was that Java is not good at date manipulation.   
Personally, I've done so little Java that I can't really speak to the  
accuracy of his statements, but the message has stuck with me--date  
manipulation is important, and needs to be got right.


To put it another way--it's one of those hard things that Perl 6 is  
trying to make easy.


--Dks



Re: date and time formatting

2005-05-31 Thread Jonathan Scott Duff
On Tue, May 31, 2005 at 01:11:21PM -0500, Rod Adams wrote:
 Nathan Gray wrote:
 possibly as an strftime() pattern.
 
 Can we please make sure that strftime() is _not_ OS dependent like the 
 POSIX version is now?

I don't mind an OS dependent strftime() as long as we have some
formatter that is OS independent.  I expect that strftime() will
eventually fall into disuse as people use the newer, better
formatters.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]


Re: date and time formatting

2005-05-31 Thread Sam Vilain

Rob Kinyon wrote:

What I'm trying to get at isn't that DateTime's API should be
preserved. I'm saying that the concept of DateTime should be ported.
Core or not core - it doesn't matter. When use'd (or installed), it
should override now() (and anyone else we can think of) to return an
object that DWIMs, plus provides the interface you've outlined below.


I've made a start on this.  See ext/Date in pugs.  I don't think that
your views are necessarily contrary.

The biggest reason I didn't use DateTime was that I found it awkward
for the common case; most of the time I just want to stuff in an
ISO8601 date.  I also don't like implicit normalisation to seconds
underneath the hood when I'm doing basic date calculations, and
the way that the DateTime base class is inherantly based on the
Gregorian calendar.

The Date and Duration roles are extremely minimal; see

   http://svn.openfoundry.org/pugs/ext/Date/lib/Date.pm
   http://svn.openfoundry.org/pugs/ext/Date/lib/Duration.pm

The major API is described at:

   http://svn.openfoundry.org/pugs/ext/Date/lib/Date/Gregorian.pod

This module is supposed to be somewhere between DateTime and
Class::Date, with built-in ISO-8601 support (as it's the standard ;)).

With a bit of luck, all Date implementation can share this `Date'
Role, and Gregorian calendar modules share the `Date::Gregorian' Role,
so that the multitude of implementations that crop up will be mutually
exchangable, and the simple case fast, efficient and useful.

Sam.