On Sun, Aug 28, 2011 at 5:39 AM, Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
> On 28 August 2011 00:39, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Sat, Aug 27, 2011 at 7:43 AM, Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
>>> On 27 August 2011 12:29, Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
>>>> ... if nothing else it has been a
>>>> fun exercise figuring out how the datetime string parsing code works.
>>>
>>> While looking through the current code, I spotted the following oddity:
>>>
>>> select timestamp 'yesterday 10:30';
>>> timestamp
>>> ---------------------
>>> 2011-08-26 10:30:00
>>>
>>> which is what you'd expect, however:
>>>
>>> select timestamp '10:30 yesterday';
>>> timestamp
>>> ---------------------
>>> 2011-08-26 00:00:00
>>>
>>> Similarly "today" and "tomorrow" reset any time fields so far, but
>>> ISTM that they should really be preserving the hour, min, sec fields
>>> decoded so far.
>>
>> Sounds right to me. Want to send a patch?
>
> The attached patch makes "today", "tomorrow" and "yesterday" only set
> the year, month and day fields. All the other fields are already
> initialised to 0 at the start, and may be set non-zero before or after
> encountering these special date values. The result should now be
> independent of the order of the fields.
OK, committed. Perhaps it should be back-patched, but since this was
only discovered during code-reading and not in the wild, I didn't
bother.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company