Re: Created feature for to_date() conversion using patterns 'YYYY-WW', 'YYYY-WW-D', 'YYYY-MM-W' and 'YYYY-MM-W-D'

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Mark Lorenz <postgres(at)four-two(dot)de>
Cc: Cleysson Lima <cleyssondba(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Created feature for to_date() conversion using patterns 'YYYY-WW', 'YYYY-WW-D', 'YYYY-MM-W' and 'YYYY-MM-W-D'
Date: 2020-02-01 20:00:53
Message-ID: 14073.1580587253@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> Either way, though, the WW weeks don't line up with the D weeks,
> and we're not likely to make them do so.
> So I think an acceptable version of this feature has to involve
> defining at least one new format code and maybe as many as three,
> to produce year, week and day values that agree on whichever
> definition of "a week" you want to use, and then to_date has to
> enforce that input uses matching year/week/day field types,
> very much like it already does for ISO versus Gregorian dates.

A different line of thought could be to accept the current to_char()
behavior for WW and D, and go ahead and teach to_date() to invert that.
That is, take YYYY plus WW as specifying a seven-day interval, and then
D chooses the matching day within that interval. This would still have
the property you complained about originally that WW-plus-D don't form
a monotonically increasing sequence, but I think that ship has sailed.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2020-02-02 00:02:04 Internal key management system
Previous Message Tom Lane 2020-02-01 19:37:55 Re: BUG #16171: Potential malformed JSON in explain output