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
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 |