Re: date and time formatting
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
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
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
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
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
date and time formatting
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. Possible syntax could be: $time_object = time(); $epoch_seconds = +$time_object; $human_readable = ~$time_object; $human_readable = $time_object.format; # default format $human_readable = $time_object.format($pattern); $human_readable = $time_object.format($pattern, offset = 'local'); The default offset would probably be 'local', and would account for daylight saving time. The offset could be changed to a floating-point value indicating hours offset from UTC. A timezone module could perhaps allow for timezone names, which would allow for daylight saving time computation for non-local times. The default offset would probably be stored in a global variable. The default format would probably be an ISO 8601 format, like: 1994-11-05T08:15:30-05:00 and the default format pattern would probably be stored in a global variable, possibly as an strftime() pattern. -kolibrie
Re: date and time formatting
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
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
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
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
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
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
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
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
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.
