Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit d677550

Browse files
committed
Allow to_date/to_timestamp to recognize non-English month/day names.
to_char() has long allowed the TM (translation mode) prefix to specify output of translated month or day names; but that prefix had no effect in input format strings. Now it does. to_date() and to_timestamp() will now recognize the same month or day names that to_char() would output for the same format code. Matching is case-insensitive (per the active collation's notion of what that means), just as it has always been for English month/day names without the TM prefix. (As per the discussion thread, there are lots of cases that this feature will not handle, such as alternate day names. But being able to accept what to_char() will output seems useful enough.) In passing, fix some shaky English and violations of message style guidelines in jsonpath errors for the .datetime() method, which depends on this code. Juan José Santamaría Flecha, reviewed and modified by me, with other commentary from Alvaro Herrera, Tomas Vondra, Arthur Zakirov, Peter Eisentraut, Mark Dilger. Discussion: https://postgr.es/m/CAC+AXB3u1jTngJcoC1nAHBf=M3v-jrEfo86UFtCqCjzbWS9QhA@mail.gmail.com
1 parent 1810ca1 commit d677550

File tree

9 files changed

+221
-54
lines changed

9 files changed

+221
-54
lines changed

doc/src/sgml/func.sgml

+21-10
Original file line numberDiff line numberDiff line change
@@ -5968,7 +5968,7 @@ SELECT regexp_match('abc01234xyz', '(?:(.*?)(\d+)(.*)){1,1}');
59685968
</row>
59695969
<row>
59705970
<entry><literal>TM</literal> prefix</entry>
5971-
<entry>translation mode (print localized day and month names based on
5971+
<entry>translation mode (use localized day and month names based on
59725972
<xref linkend="guc-lc-time"/>)</entry>
59735973
<entry><literal>TMMonth</literal></entry>
59745974
</row>
@@ -5999,9 +5999,20 @@ SELECT regexp_match('abc01234xyz', '(?:(.*?)(\d+)(.*)){1,1}');
59995999

60006000
<listitem>
60016001
<para>
6002-
<literal>TM</literal> does not include trailing blanks.
6003-
<function>to_timestamp</function> and <function>to_date</function> ignore
6004-
the <literal>TM</literal> modifier.
6002+
<literal>TM</literal> suppresses trailing blanks whether or
6003+
not <literal>FM</literal> is specified.
6004+
</para>
6005+
</listitem>
6006+
6007+
<listitem>
6008+
<para>
6009+
<function>to_timestamp</function> and <function>to_date</function>
6010+
ignore letter case in the input; so for
6011+
example <literal>MON</literal>, <literal>Mon</literal>,
6012+
and <literal>mon</literal> all accept the same strings. When using
6013+
the <literal>TM</literal> modifier, case-folding is done according to
6014+
the rules of the function's input collation (see
6015+
<xref linkend="collation"/>).
60056016
</para>
60066017
</listitem>
60076018

@@ -12824,12 +12835,12 @@ table2-mapping
1282412835
<para>
1282512836
The <literal>datetime()</literal> and
1282612837
<literal>datetime(<replaceable>template</replaceable>)</literal> methods
12827-
use the same parsing rules as <literal>to_timestamp</literal> SQL
12828-
function does (see <xref linkend="functions-formatting"/>) with three
12829-
exceptions. At first, these methods doesn't allow unmatched template
12830-
patterns. At second, only following separators are allowed in the
12831-
template string: minus sign, period, solidus, comma, apostrophe,
12832-
semicolon, colon and space. At third, separators in the template string
12838+
use the same parsing rules as the <literal>to_timestamp</literal> SQL
12839+
function does (see <xref linkend="functions-formatting"/>), with three
12840+
exceptions. First, these methods don't allow unmatched template
12841+
patterns. Second, only the following separators are allowed in the
12842+
template string: minus sign, period, solidus (slash), comma, apostrophe,
12843+
semicolon, colon and space. Third, separators in the template string
1283312844
must exactly match the input string.
1283412845
</para>
1283512846
</note>

0 commit comments

Comments
 (0)