Thomas Lockhart wrote:
>
> Because of the common and documented cutoff date (1970 currently, 1950
> in some other apps) used to solve this problem.
Most database software I have seen uses some form of setting to control
the actual date used here, and that is the most long-term solution.
somethi
> I don't worry, we have to_char/date already better than original
> Oracle's to_char() :-)
:)
Yes, and you'll find that the code will settle down and need very little
attention from here on. Our other date/time code has been around for 3
or 4 years now, and goes months without anyone even aski
On Sat, 11 Nov 2000, Thomas Lockhart wrote:
> > > This case I *would* have expected to produce 1 BC, but nope...
> > Where is *guarantee* that the year is 4-digits?!
>
> There is no guarantee of only four digits, but there is a convention
> that two digit years refer to the current/previous/ne
(Sorry for diving in late; I was out of town the last few days)
> > This case I *would* have expected to produce 1 BC, but nope...
> Where is *guarantee* that the year is 4-digits?!
There is no guarantee of only four digits, but there is a convention
that two digit years refer to the current/pr
On Wed, 8 Nov 2000, Tom Lane wrote:
> Karel Zak <[EMAIL PROTECTED]> writes:
> >> 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 doe
Karel Zak <[EMAIL PROTECTED]> writes:
>> 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 sensib
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.
Sinc
On Tue, 7 Nov 2000, Tom Lane wrote:
> Kate Collins <[EMAIL PROTECTED]> 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
> --
