> On Mon, Aug 07, 2000 at 01:44:28AM -0500, Jonathan Scott Duff wrote:
> > On Sun, Aug 06, 2000 at 11:07:02AM -0700, Russ Allbery wrote:
> > > Basically, you don't want to go anywhere near this mess; it eats people.
> >
> > I agree.
> >
> > > I see two reasonable options to go with instead. One is to just use a
> > > binary flag that says use UTC or not; this is the simplest and most
> > > reliable to explain. The other is to allow a timezone offset; this
> > > doesn't deal with daylight savings time and historic time zone changes,
> > > but it provides enough power for most of what people want to do and if you
> > > want to deal with the rest you have to deal with time zone naming.
>
> I agree completely with Russ, and I would further state that I don't
> want this C<date> feature in the core. Dates, times, timezones, leap
> seconds, month and day names, localized formats, etc., are too
> complex. No one here has thought out the complexity enough to say
> "this is what Perl will support from now on".
>
> Currently, there isn't even an adequate (in my opinion) module on CPAN
> that gives dates a proper abstract interface. Time::Object may be
> okay as a lightweight localtime/strftime interface, but it does not
> support date, as opposed to time/date, arithmetic, or rather, it
> mis-supports it.
Well its called Time::Object, not Date::Object for a reason... :)
> Since we really don't understand dates here, I don't want us commiting
> to a certain interface without a `use' directive in the program.
> Distribute Time::Object as a standard module, but keep it a module,
> and don't force its quirks on people. Certainly, don't force the
> complex, quirky, and untested interface being developed here now on
> anyone without a long, patient discussion period.
>
> > This makes an incredible amount of sense. We could even let the user
> > specify a coderef to a sub that implements their own particular
> > timezone oddities. (i.e. a sub to tell date() what the TZ offset is)
>
> Gross. Put it in a module.
While I think Time::Object is a really great module, and following these
discussions I'm thinking of adding a date() function to it, I'm actually in
total agreement with John here. Times and dates are something that should be
supported _simply_ by the core of Perl, and more extensively in an external
module. I'd be very happy to see the Time::Object in core perl as a module,
but I'd hate to see it as the _only_ interface to dates. And the extensions
being proposed here just seem like bloat to me. And John is totally correct:
Time::Object attempts to do some datetime arithmetic, but doing this sort of
thing properly for dates alone is really a tough nut to crack, and not
something that we need put in the core. There are modules out there to do
this sort of thing, lets keep it that way (or improve them enough to put in
core).
The only part of this proposal that I like is Damian's WANTHASH extension
which would allow localtime{'day', 'month', 'year'}.
I'm also really aware that trying to change localtime in an array context to
return the real year is going to be a very painful change. There are lots of
simple scripts that use localtime that I wouldn't have thought people will
want to run through the p5top6 conversion script just to get running on a
newer perl. (and then theres the issue of how you detect the addition of
1900 to the year even using the B::* stuff).
BTW: Since I'm not subscribed to p6-lang (I think you guys would kill my 64k
link!), I'd just like to say that just because strftime() is a unix-ism or
POSIX-ism, does not mean that its bad. Programmers know strftime, they've
heard of strftime, lets not try and confuse things by doing a "Java" and
inventing our own new date formatting functions with new format specifiers.
Perl is not about NIH.
--
<Matt/>
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org
