Applied, with a function rename. The only odd case we have left is:
test=> select to_date('079', 'YYY');
to_date
1979-01-01
(1 row)
(Note the zero is ignored.) I can't see an easy way to fix this and
continue to be easily documented.
---
Bruce Momjian wrote:
> Piyush Newe wrote:
> > Hi,
> >
> > I was randomly testing some date related stuff on PG & observed that the
> > outputs were wrong.
> >
> > e.g.
> > postgres=# SELECT TO_DATE('01-jan-2010', 'DD-MON-YY');
> > to_date
> >
> > 3910-01-01 <- Look at th
Piyush Newe wrote:
> Hi,
>
> I was randomly testing some date related stuff on PG & observed that the
> outputs were wrong.
>
> e.g.
> postgres=# SELECT TO_DATE('01-jan-2010', 'DD-MON-YY');
> to_date
>
> 3910-01-01 <- Look at this
> (1 row)
>
> postgres=# SELECT TO_DATE
Any inputs further ?
On Tue, Mar 22, 2011 at 2:37 PM, Piyush Newe
wrote:
> Thanks Heikki, Tom & Robert for your valuable inputs.
>
> According to the code, PG is behaving what is mentioned below.
>
> 1. Format = Y
> 0 ... 9 = 2000 ... 2009 (we are always adding 2000 to the year)
>
> 2. Format =
Thanks Heikki, Tom & Robert for your valuable inputs.
According to the code, PG is behaving what is mentioned below.
1. Format = Y
0 ... 9 = 2000 ... 2009 (we are always adding 2000 to the year)
2. Format = YY
00 ... 69 = 2000 ... 2069 (we are adding 2000 to the year)
70 ... 99 = 1970 ... 1999
On Mon, Mar 21, 2011 at 12:39 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Mar 21, 2011 at 10:18 AM, Tom Lane wrote:
>>> As far as I can see, that would completely destroy the use-case of
>>> trying to parse a string where there's not non-digit delimiters and
>>> so you have to take exac
Robert Haas writes:
> On Mon, Mar 21, 2011 at 10:18 AM, Tom Lane wrote:
>> As far as I can see, that would completely destroy the use-case of
>> trying to parse a string where there's not non-digit delimiters and
>> so you have to take exactly the specified number of digits, not more.
> Yeah, I
On Mon, Mar 21, 2011 at 10:18 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Mar 21, 2011 at 9:57 AM, Tom Lane wrote:
>>> What I was thinking was that would take either 2 or 4 digits.
>>> Whatever you do here, the year will have to be delimited by a non-digit
>>> for such cases to be
Robert Haas writes:
> On Mon, Mar 21, 2011 at 9:57 AM, Tom Lane wrote:
>> What I was thinking was that would take either 2 or 4 digits.
>> Whatever you do here, the year will have to be delimited by a non-digit
>> for such cases to be parseable.
> I was assuming a slightly more general vari
On Mon, Mar 21, 2011 at 9:57 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Mar 21, 2011 at 6:24 AM, Heikki Linnakangas
>> wrote:
Having said that, it's not entirely clear to me what sane behavior is
here. Personally I would expect that an n-Ys format spec would consume
at
Robert Haas writes:
> On Mon, Mar 21, 2011 at 6:24 AM, Heikki Linnakangas
> wrote:
>>> Having said that, it's not entirely clear to me what sane behavior is
>>> here. Personally I would expect that an n-Ys format spec would consume
>>> at most n digits from the input. Otherwise how are you goin
On Mon, Mar 21, 2011 at 6:24 AM, Heikki Linnakangas
wrote:
>>> Having said that, it's not entirely clear to me what sane behavior is
>>> here. Personally I would expect that an n-Ys format spec would consume
>>> at most n digits from the input. Otherwise how are you going to use
>>> to_date to p
On 21.03.2011 07:40, Piyush Newe wrote:
On Thu, Mar 17, 2011 at 7:56 PM, Tom Lane wrote:
Robert Haas writes:
On Thu, Mar 17, 2011 at 9:46 AM, Alvaro Herrera
wrote:
Keep in mind that the datetime stuff was abandoned by the maintainer
some years ago with quite some rough edges. Some of it
On Thu, Mar 17, 2011 at 7:56 PM, Tom Lane wrote:
> Robert Haas writes:
> > On Thu, Mar 17, 2011 at 9:46 AM, Alvaro Herrera
> > wrote:
> >> Keep in mind that the datetime stuff was abandoned by the maintainer
> >> some years ago with quite some rough edges. Some of it has been fixed,
> >> but a
Tom Lane wrote:
> what we should first do is see what Oracle does in such cases,
> because the main driving factor for these functions is Oracle
> compatibility not what might seem sane in a vacuum.
+1
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make cha
Excerpts from Robert Haas's message of jue mar 17 11:09:56 -0300 2011:
> On Thu, Mar 17, 2011 at 9:46 AM, Alvaro Herrera
> wrote:
> > Keep in mind that the datetime stuff was abandoned by the maintainer
> > some years ago with quite some rough edges. Some of it has been fixed,
> > but a lot of b
Robert Haas writes:
> On Thu, Mar 17, 2011 at 9:46 AM, Alvaro Herrera
> wrote:
>> Keep in mind that the datetime stuff was abandoned by the maintainer
>> some years ago with quite some rough edges. Some of it has been fixed,
>> but a lot of bugs remain. Looks like this is one of those places an
On Thu, Mar 17, 2011 at 9:46 AM, Alvaro Herrera
wrote:
> Excerpts from Piyush Newe's message of jue mar 17 02:30:06 -0300 2011:
>> Sorry for creating the confusion. The table drawn was PostgreSQL vs EDB
>> Advanced Server.
>> Thanks Burce for clarification.
>>
>> For the 1-digit, 2-digit & 3-digit
Excerpts from Piyush Newe's message of jue mar 17 02:30:06 -0300 2011:
> Sorry for creating the confusion. The table drawn was PostgreSQL vs EDB
> Advanced Server.
> Thanks Burce for clarification.
>
> For the 1-digit, 2-digit & 3-digit Year inputs, as I said, I didn't see any
> document in PG whi
Sorry for creating the confusion. The table drawn was PostgreSQL vs EDB
Advanced Server.
Thanks Burce for clarification.
For the 1-digit, 2-digit & 3-digit Year inputs, as I said, I didn't see any
document in PG which will explain what would be the century considered if it
is not given. If I misse
Robert Haas wrote:
> On Wed, Mar 16, 2011 at 5:52 PM, Bruce Momjian wrote:
> > Robert Haas wrote:
> >> On Wed, Mar 16, 2011 at 8:21 AM, Piyush Newe
> >> wrote:
> >> > Data Format ?? ? ? ? ? ? ? ?PostgreSQL EDBAS
> >> > TO_DATE('01-jan-10', ?'DD-MON-Y') ?? ? ? ?2010-01-01 Error
> >> > TO_DATE('01-
On Wed, Mar 16, 2011 at 5:52 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Wed, Mar 16, 2011 at 8:21 AM, Piyush Newe
>> wrote:
>> > Data Format ?? ? ? ? ? ? ? ?PostgreSQL EDBAS
>> > TO_DATE('01-jan-10', ?'DD-MON-Y') ?? ? ? ?2010-01-01 Error
>> > TO_DATE('01-jan-10', ?'DD-MON-YY') ?? ? ? ?20
Robert Haas wrote:
> On Wed, Mar 16, 2011 at 8:21 AM, Piyush Newe
> wrote:
> > Data Format ?? ? ? ? ? ? ? ?PostgreSQL EDBAS
> > TO_DATE('01-jan-10', ?'DD-MON-Y') ?? ? ? ?2010-01-01 Error
> > TO_DATE('01-jan-10', ?'DD-MON-YY') ?? ? ? ?2010-01-01 01-JAN-2010
> > TO_DATE('01-jan-10', ?'DD-MON-YYY') 2
On Wed, Mar 16, 2011 at 8:21 AM, Piyush Newe
wrote:
> Data Format PostgreSQL EDBAS
> TO_DATE('01-jan-10', 'DD-MON-Y') 2010-01-01 Error
> TO_DATE('01-jan-10', 'DD-MON-YY') 2010-01-01 01-JAN-2010
> TO_DATE('01-jan-10', 'DD-MON-YYY') 2010-01-01 01-JAN-2010
> TO_DATE
Hi,
I was randomly testing some date related stuff on PG & observed that the
outputs were wrong.
e.g.
postgres=# SELECT TO_DATE('01-jan-2010', 'DD-MON-YY');
to_date
3910-01-01 <- Look at this
(1 row)
postgres=# SELECT TO_DATE('01-jan-2010', 'DD-MON-');
to_date
--
25 matches
Mail list logo
