Dates and times are not "simple things". If you consider different
calendars, timezones, regionalization, and user preferences, dates and times
are quite complex. Also, datetime has an infinite domain in both duration
and precision. That's always a tough problem for a finite computer to
handle.
"Neil Campbell" <batneil_at_lineone.net> wrote in message
news:3BF48BFF.7010906_at_lineone.net...
> Jim Kennedy wrote:
>
> > All the commercial rdbmss that I know of store date and time as 1
> > field.(admittedly I don't know them all.) What databases are you
thinking
> > of that store it in 2 different fields?
> >
>
>
> The two I've used so far are PostgreSQL and mySQL, both of which support
> separate Date/Time datatypes (as defined by SQL-92, I believe). I admit
> that this may be rare, as I haven't looked at any other dbmses.
>
>
> > Why not just ignore the component you don't need? So getDate for Oracle
> > would just get the date part and getTime would just get the time part.
>
>
> So you're suggesting that getTime() on an Oracle Date field would take
> the time component and ignore the date part? Hmmm. To be honest, this
> hadn't occurred to me - I suppose I just assumed that getTime() wouldn't
> work well on a date field. I'll check this out, though - thanks.
>
>
> > You are going to have to write database specific code in any event or
you
> > are going to have to code for the lowest common denominator which will
give
> > you a whole set of other problems.
>
>
> This is rather what I was afraid of. I was sort of hoping that the SQL
> standard would allow me sufficient database-independance to cope with
> simple things like dates and times without writing code specific to each
> different dbms.
>
> Thanks very much for the tips though - I'll see how far I get.
>
> Neil
>
Received on Fri Nov 16 2001 - 08:35:08 CST
