Re: Bug in to_timestamp().

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Artur Zakirov <a(dot)zakirov(at)postgrespro(dot)ru>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Alex Ignatov <a(dot)ignatov(at)postgrespro(dot)ru>, Bruce Momjian <bruce(at)momjian(dot)us>, amul sul <sul_amul(at)yahoo(dot)co(dot)in>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Bug in to_timestamp().
Date: 2016-07-14 09:16:34
Message-ID: CAFj8pRDGxe=cdcZ7pur=2WeW9O3MQCZTBEAOJfQ7OLQJaYXDvw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2016-07-14 11:05 GMT+02:00 Artur Zakirov <a(dot)zakirov(at)postgrespro(dot)ru>:

> On 23.06.2016 21:02, Tom Lane wrote:
>
>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>
>>> On Thu, Jun 23, 2016 at 1:40 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>
>>>> At the very least I'd want to see a thought-through proposal that
>>>> addresses all three of these interrelated points:
>>>>
>>>> * what should a space in the format match
>>>> * what should a non-space, non-format-code character in the format match
>>>> * how should we handle fields that are not exactly the width suggested
>>>> by the format
>>>>
>>>
>> I'm not averse to some further study of those issues, and I think the
>>> first two are closely related. The third one strikes me as a somewhat
>>> separate consideration that doesn't need to be addressed by the same
>>> patch.
>>>
>>
>> If you think those issues are not interrelated, you have not thought
>> about it carefully enough.
>>
>> As an example, what we can do to handle not-expected-width fields is
>> very different if the format is "DDMMYY" versus if it is "DD-MM-YY".
>> In the first case we have little choice but to believe that each
>> field is exactly two digits wide. In the second case, depending on
>> how we decide to define matching of "-", we might be able to allow
>> the field widths to vary so that they're effectively "whatever is
>> between the dashes". But that would require insisting that "-"
>> match a "-", or at least a non-alphanumeric, which is not how it
>> behaves today.
>>
>> I don't want to twiddle these behaviors in 9.6 and then again next year.
>>
>> regards, tom lane
>>
>>
>>
> Hi,
>
> I want to start work on this patch.
>
> As a conclusion:
> - need a decision about three questions:
>
>
>> * what should a space in the format match
>> * what should a non-space, non-format-code character in the format match
>> * how should we handle fields that are not exactly the width suggested
>> by the format
>>
>
> - nobody wants solve this issue in 9.6.
>
> And I have question: what about wrong input in date argument? For example,
> from Alex's message:
>
> postgres=# SELECT TO_TIMESTAMP('2016-02-30 15:43:36', 'YYYY-MM-DD
>> HH24:MI:SS');
>> to_timestamp
>> ------------------------
>> 2016-03-01 15:43:36+03
>> (1 row)
>>
>
> Here '2016-02-30' is wrong date. I didn't see any conclusion about this
> case in the thread.
>

last point was discussed in thread related to to_date_valid function.

Regards

Pavel

>
> --
> Artur Zakirov
> Postgres Professional: http://www.postgrespro.com
> Russian Postgres Company
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kenan Yao 2016-07-14 09:53:40 Hang issue when COPY to/from an unopened FIFO
Previous Message Artur Zakirov 2016-07-14 09:05:58 Re: Bug in to_timestamp().