Re: to_date problems (Re: Favor for Postgres User at WSI) - Mailing list pgsql-bugs

From Kate Collins
Subject Re: to_date problems (Re: Favor for Postgres User at WSI)
Date
Msg-id 3A096E6A.24288239@wsicorp.com
Whole thread Raw
In response to Re: to_date problems (Re: Favor for Postgres User at WSI)  (Karel Zak <zakkr@zf.jcu.cz>)
List pgsql-bugs
Tom and Karel,

Thank you for your responses.

Based on your email, I have worked out a solution.

The reason I am using the to_date function is because I have two data bases into
which I am inserting, one is postgres, the other Oracle.  So I need a syntax
solution which will work with both.

Since I am actually using perl to connect to the data bases, I could modify the code
to parse the date string before it creates the insert statement.  I have done this
with other syntax differences, but I am trying to keep this to a minimum.

Another issue is that my input date string is coming from an external source.  It is
part of a message which I am parsing, and putting in the data base.  The format of
the date string is YYMMDD.

So, I have created a function:

pbi=# create function my_to_date( text, text) returns timestamp
pbi-# as 'select $1::timestamp'
pbi-# language 'sql';

which when run, returns:

pbi=# select my_to_date( '001112', 'yymmdd');
       my_to_date
------------------------
 2000-11-12 00:00:00+00
(1 row)

I made my function look like the the real one, although it does not use the second
argument.  I may modify this to use the second argument and/or to add punctuation (
/, :, -) to the time string to make it less ambiguous.

Any way, thank you both again for your help.

Cheers,
Kate

Karel Zak wrote:

> On Tue, 7 Nov 2000, Tom Lane wrote:
>
> > Kate Collins <klcollins@wsicorp.com> writes:
> > >> In other words it is defaulting to the year 0 (actually year 1 BC, since
> > >> there is no year 0) instead of 2000.
> >
> > Hmm, you're right:
> >
> > regression=# select to_date( '001112', 'YYMMDD');
> >     to_date
> > ---------------
> >  0001-11-12 BC
> > (1 row)
> >
> > >> Now I run the equivalent select statement on Oracle, and I get:
> > >> select to_char( to_date( '001112', 'YYMMDD'), 'YYYYMMDD') from dual;
> > >> TO_CHAR(TO_DATE('001112','YYMMDD'),'YYYYMMDD')
> > >> ---------------------------------------------------------------------------
> > >> 20001112
> > >>
> > >> Which is what I expect.
> > >>
> > >> Is "YY" suppose to default to the current century or is this an
> > >> Oracle'ism?
> >
> > I dunno whether there is any actual spec for to_date(), but I do agree
> > that if you've specified a 2-digit YY format, something 2000-centric
> > would be more useful than the current behavior.
> >
> > It doesn't seem to be doing anything particularly sensible with a
> > 4-digit date, either:
> >
> > regression=# select to_date( '00001112', 'YYYYMMDD');
> >   to_date
> > ------------
> >  1112-11-12
> > (1 row)
> >
> > This case I *would* have expected to produce 1 BC, but nope...
>
>  Where is *guarantee* that the year is 4-digits?!
>
> test=# select '123456-11-12'::date;
>    ?column?
> --------------
>  123456-11-12
> (1 row)
>
> The to_char/timestamp not try expect that YYYY = 4-digits (see docs)
>
> test=# select to_char('123456-11-12'::timestamp, 'YYYY DD/Mon');
>     to_char
> ---------------
>  123456 12/Nov
> (1 row)
>
> I mean that use in to_date() year in the first position is not good
> idea, better is try:
>
> test=# select to_date('11122000', 'MMDDYYYY');
>   to_date
> ------------
>  2000-11-12
>
> And 'YY' - it's hell, what is '00'? ... 1900 or 2000 or 20000?
>
> >
> > >> BTW, on postgres, when I try:
> > >> select to_char( to_date( '20001112', 'YYYYMMDD'), 'YYYYMMDD');
> > >> I get the error:  "ERROR:  Unable to convert timestamp to date"
> >
> > That seems broken in current sources, too:
> >
> > regression=# select to_date( '20001112', 'YYYYMMDD');
> > ERROR:  Unable to convert timestamp to date
>
> Yes, because to_date() expect that year is '20001112' and internal
> PG's date/time routines disable convert it.
>
> test=# select to_date( '2000-1112', 'YYYY-MMDD');
>   to_date
> ------------
>  2000-11-12
>
> > Looks like you've rooted out a number of problems in to_date (which
> > in fairness is new-in-7.0 code).  I've cc'd this to to_date's author,
> > whom I hope will find a fix for 7.1.
>
>  How? Create limit for YYYY to 4-digits?
>
> > BTW, direct conversion to timestamp does something sensible in all
> > these cases:
> >
> > regression=# select  '001112'::timestamp;
> >         ?column?
> > ------------------------
> >  2000-11-12 00:00:00-05
> > (1 row)
>
> Why not 1900?
>
> test=# select to_char('1900-11-12'::date, 'YYDDMM')::timestamp;
>         ?column?
> ------------------------
>  2000-12-11 00:00:00+01
> (1 row)
>
> What is right here? Really '00' = 2000? .... but input is 1900
>
> > regression=# select  '00001112'::timestamp;
> >    ?column?
> > ---------------
> >  0001-11-12 BC
> > (1 row)
> >
> > regression=# select  '20001112'::timestamp;
> >         ?column?
> > ------------------------
> >  2000-11-12 00:00:00-05
> > (1 row)
>
> Well, thy use this logic for greater year:
>
>  test=# select  '20000-11-12'::timestamp;
>       ?column?
> ---------------------
>  20000-11-12 00:0000
> (1 row)
>
> test=# select  '200001112'::timestamp;
> ERROR:  Bad timestamp external representation '200001112'
> test=#
>
> ???
>
>  Well, possible solution: to_timestamp/date see if in the input is
> some separator (non-digit char) between YYYY and next template (like DD),
> if separator not here to_date() will expect 4-digits year.
>
>  '20001112'     not separator --> 4-digits for year = 2000
>  '20000-11-12'  separator '-' --> read it as 20000
>
>  '200001112'    not separator --> 4-digits for year = 2000
>                               --> 2-digits for month = 01
>                               --> 2-digits for day = 11
>                               --> last '2' is ignored
>
>  With 'YY' *hell* I not sure... add current year IMHO not must be
> correct. I mean that correct solution is:
>
> test=# select to_date('00-12-11', 'YY-DD-MM');
> ERROR:  Can't convert 'YY' to a real year.
>
> But if users want for their Oracle->PG port use 'YY' as last two digits
> in the current year, not problem make it....
>
>                                 Karel

--
=================================================
Katherine (Kate) L. Collins
Senior Software Engineer/Meteorologist
Weather Services International (WSI Corporation)
4 Federal Street
Billerica, MA 01821
EMAIL:  klcollins@wsicorp.com
PHONE:  (978) 670-5110
FAX:    (978) 670-5100
http://www.intellicast.com

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: backend closed the channel unexpectedly?!?
Next
From: Tom Lane
Date:
Subject: Re: Re: to_date problems (Re: Favor for Postgres User at WSI)