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.
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.
-John
