Having read all of these emails I am clear that, to paraphrase the song
"there is nothing like a date,
nothing in the world,
there is nothing you can name
that is anything like a date"

And then of course there is Microsoft.

But does anybody remember HyperScript? That has some interesting problems with dates as well. And then of course there is the well known Informix DBDATE bug where we couldn't query dates in UK even if we set DBDATE=dmy4/.

I don't think that Informix can point the finger at others when they can't always get it right themselves and have only learnt quite recently that other parts of the world use different date conventions.

And as fot DATETIME - the computer industry can't resolve the problems with dates. Whats wrong with star date 35721.45623

regards

Malcolm (very bored today folks:-0)

sending to informix-list

malcolm.iiug@btopenworld.com wrote:

> Having read all of these emails I am clear that, to paraphrase the song
> "there is nothing like a date,
> nothing in the world,
> there is nothing you can name
> that is anything like a date"
>
> And then of course there is Microsoft.
>
> But does anybody remember HyperScript? That has some interesting
> problems with dates as well. And then of course there is the well
> known Informix DBDATE bug where we couldn't query dates in UK even
> if we set DBDATE=dmy4/.

I never used Hyperscript seriously. The DBDATE bug to which you refer
was in I4GL, not the servers, and was fixed a long time ago - 8 years
or more ago.

> I don't think that Informix can point the finger at others when
> they can't always get it right themselves and have only learnt
> quite recently that other parts of the world use different date
> conventions.

DBDATE was introduced circa 1986, with ISQL 1.10. How much longer ago
do you take it to be before it is not 'quite recently' that Informix
took various date formats for granted.

> And as fot DATETIME - the computer industry can't resolve the
> problems with dates. Whats wrong with star date 35721.45623

What's your specific beef about DATETIME? Apart from the fact that it
isn't spelled TIME, TIME(n), TIMESTAMP, TIMESTAMP(n), optionally with
a WITH TIME ZONE clause? Yes, the DATETIME() YEAR TO SECOND
constructors are more complex than average -- the standard SQL is with
TIMESTAMP is simpler. The need to repeat yourself in INTERVAL DAY(6)
TO DAY is irksome. But it stores dates reliably, and calculates
reliably, so you must have some specific problem in mind?

--
Jonathan Leffler #include <disclaimer.h>
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/