Re: date and time formatting

13 views
Skip to first unread message

David Storrs

unread,
May 31, 2005, 12:14:00 PM5/31/05
to Perl6 Language List

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

> On 5/31/05, Nathan Gray <koli...@graystudios.org> 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

Rob Kinyon

unread,
May 31, 2005, 1:16:32 PM5/31/05
to David Storrs, Perl6 Language List
> > 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

Rod Adams

unread,
May 31, 2005, 2:11:21 PM5/31/05
to perl6-l...@perl.org
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

David Storrs

unread,
May 31, 2005, 2:31:33 PM5/31/05
to Rob Kinyon, Perl6 Language List
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

David Storrs

unread,
May 31, 2005, 2:10:32 PM5/31/05
to Rob Kinyon, Perl6 Language List

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

Rob Kinyon

unread,
May 31, 2005, 2:22:05 PM5/31/05
to David Storrs, Perl6 Language List
> - 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

Jonathan Scott Duff

unread,
May 31, 2005, 3:04:00 PM5/31/05
to Rod Adams, perl6-l...@perl.org

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
du...@pobox.com

Sam Vilain

unread,
May 31, 2005, 11:42:57 PM5/31/05
to Rob Kinyon, David Storrs, Perl6 Language List
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.

Nathan Gray

unread,
Jun 1, 2005, 9:32:39 AM6/1/05
to Sam Vilain, Rob Kinyon, David Storrs, Perl6 Language List
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

Paul Seamons

unread,
Jun 2, 2005, 11:43:56 AM6/2/05
to perl6-l...@perl.org
> 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

Juerd

unread,
Jun 2, 2005, 11:53:08 AM6/2/05
to Paul Seamons, perl6-l...@perl.org
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

Rob Kinyon

unread,
Jun 3, 2005, 8:32:07 AM6/3/05
to Paul Seamons, perl6-l...@perl.org
> 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

Reply all
Reply to author
Forward
0 new messages