I have always had a particular affection for Dates as Julian day
numbers the number of days since xxxx.
They are really easy to manipulate, compare, Virtually all the
nasty aspects of dates become a function of the routines for printing
them or inputting them, Ignoring issues of the differing calendars used
prior to the late 1700's you can represent most of recorded history in a
3 byte integer.
I have never understood why most databases tended to store dates
in any other format.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 21, 2003 1:34 PM
To: Dave Rolsky
Cc: John Siracusa; DBI Dev
Subject: Re: Integrating date and time parsing and formatting
Let me put in a plug for separate DATE and DATETIME types. I don't know
whether the datetime list has discussed this, and the last time I tried
to join the list, I kept getting some weird error.
Dates are like the integers. Datetimes are like the real numbers. The
existence of timezones and dst makes the two systems rather
incompatible, so one is not really a subset of the other. See
Date::Simple for an implementation of the DATE type without (most) time
and tz complications.
I firmly agree with the gist of John Siracusa's original message. I
hope no one here underestimates the difficulty when times are involved.
Thanks
-John
Dave Rolsky <[EMAIL PROTECTED]> on 01/21/2003 01:14:02 PM
To: John Siracusa <[EMAIL PROTECTED]>
cc: DBI Dev <[EMAIL PROTECTED]> (bcc: John Tobey/Intdata)
Subject: Re: Integrating date and time parsing and formatting
On Tue, 21 Jan 2003, John Siracusa wrote:
> On 1/21/03 3:38 AM, H.Merijn Brand wrote:
> > FWIW *if* there should be a default date format for DBI, *please*
> > make
it
> > universal: YYYYMMDD and not MMDDYYYY or MM/DD/YYYY, because you have
> > no
idea
> > how much irritation this arouses in European countries.
>
> Like I said:
>
> > On 1/20/03 11:34 AM, John Siracusa wrote:
> >> It would be nice if we had a "canonical" date/time representation.
That's
> >> part of what the new DateTime modules being discussed on the
> >> [EMAIL PROTECTED] mailing list hope to deliver.
>
> I don't think we'll have a standardized "interchange format" for dates
> until/unless the new DateTime project matures. But such a thing is
> not required for database-independent code, provided you're not trying
> to
move
> data from one database to another. All that's required by my proposal
> is that each DBD's formatter be able to read whatever is returned from
> its
own
> parser:
And what would be returned is a DateTime object, which would have
methods like "year", "month", and so on. That way there's no need to
say that the universal format is X. That's not really possible anyway,
since each DBMS has its own default date formats.
-dave
/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/
