Thread: External Open Standards
Do we have a full list of externally defined open standards that we follow? Are there any known incompatibilities from externally defined open standards? (I know about the SQL standard stuff). Are there any things that need standards that don't have them? (Be brief) Some high level general questions that may shake out something useful requirements. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On lör, 2012-05-12 at 10:37 +0100, Simon Riggs wrote: > Do we have a full list of externally defined open standards that we > follow? Well, there are a lot of them, starting with things like ASCII and ANSI C. If you grep through the documentation for things like "RFC" or "ISO", you will find a number of references. But I don't know of a ready-made list.
On Sat, May 12, 2012 at 5:37 AM, Simon Riggs <simon@2ndquadrant.com> wrote: > Do we have a full list of externally defined open standards that we follow? > > Are there any known incompatibilities from externally defined open standards? > (I know about the SQL standard stuff). The documentation is misleading to the point of our support for ISO 8601-strict parsing. http://archives.postgresql.org/pgsql-hackers/2012-02/msg01237.php A very fine point, but I discovered it not out of curiosity, but a fairly angry user on Twitter. We can define the problem away since the space-inclusive format is so common...so much so, that it is codified in RFC 3339 (http://www.ietf.org/rfc/rfc3339.txt). The only problem, then, is the DATESTYLE "ISO" labeling: changing that would be really painful, so perhaps another solution is to parse the "T" demanded by 8601, presuming no other details come to light. -- fdr
On 20 May 2012 01:52, Daniel Farina <daniel@heroku.com> wrote: > The documentation is misleading to the point of our support for ISO > 8601-strict parsing. > > http://archives.postgresql.org/pgsql-hackers/2012-02/msg01237.php > > A very fine point, but I discovered it not out of curiosity, but a > fairly angry user on Twitter. > > We can define the problem away since the space-inclusive format is so > common...so much so, that it is codified in RFC 3339 > (http://www.ietf.org/rfc/rfc3339.txt). The only problem, then, is the > DATESTYLE "ISO" labeling: changing that would be really painful, so > perhaps another solution is to parse the "T" demanded by 8601, > presuming no other details come to light. We may be wandering a bit off-topic from Simon's OP, but I'll bite. We already do *parse* the 'T' in datetime input: postgres=# select timestamp '2012-05-21T15:05'; timestamp ---------------------2012-05-21 15:05:00 (1 row) What we don't do is *output* the 'T', but this is pretty easy to workaround, e.g., to_char(now(), 'YYYY-MM-DD"T"HH24:MI:SS'). The scope of actually wanting the 'T' is surely pretty minor? I'd be okay with just adding a note in the manual under Date/Time Output to the effect of "Note: ISO 8601 specifies the use of uppercase letter 'T' to separate the date and time. Postgres uses a space for improved readability, in line with other database systems and RFC 3339." Cheers, BJ
On Sun, May 20, 2012 at 10:34 PM, Brendan Jurd <direvus@gmail.com> wrote: > What we don't do is *output* the 'T', but this is pretty easy to > workaround, e.g., to_char(now(), 'YYYY-MM-DD"T"HH24:MI:SS'). The > scope of actually wanting the 'T' is surely pretty minor? > > I'd be okay with just adding a note in the manual under Date/Time > Output to the effect of "Note: ISO 8601 specifies the use of uppercase > letter 'T' to separate the date and time. Postgres uses a space for > improved readability, in line with other database systems and RFC > 3339." Yes, I believe you are quite right. My mistake, and I like your suggestion, too, as it has successfully informed me of the most accurate rendition of this. -- fdr
Brendan Jurd <direvus@gmail.com> writes:
> I'd be okay with just adding a note in the manual under Date/Time
> Output to the effect of "Note: ISO 8601 specifies the use of uppercase
> letter 'T' to separate the date and time. Postgres uses a space for
> improved readability, in line with other database systems and RFC
> 3339."
Done that way, though I adjusted the wording to make it clear that
we do allow the 'T' for input.
regards, tom lane
On lör, 2012-05-19 at 11:52 -0400, Daniel Farina wrote: > The documentation is misleading to the point of our support for ISO > 8601-strict parsing. > > http://archives.postgresql.org/pgsql-hackers/2012-02/msg01237.php > > A very fine point, but I discovered it not out of curiosity, but a > fairly angry user on Twitter. > > We can define the problem away since the space-inclusive format is so > common...so much so, that it is codified in RFC 3339 > (http://www.ietf.org/rfc/rfc3339.txt). The only problem, then, is the > DATESTYLE "ISO" labeling: changing that would be really painful, so > perhaps another solution is to parse the "T" demanded by 8601, > presuming no other details come to light. The problem is that people think that "ISO" means ISO 8601, whereas it actually means ISO 9075. I can see how that's an easy mistake to make, though.
Peter Eisentraut <peter_e@gmx.net> writes:
> The problem is that people think that "ISO" means ISO 8601, whereas it
> actually means ISO 9075. I can see how that's an easy mistake to make,
> though.
... especially since we keep referring to 8601 in our own docs.
Does this mean we should do a global s/8601/9075/ in the docs?
regards, tom lane
On 22 May 2012 02:58, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Peter Eisentraut <peter_e@gmx.net> writes: >> The problem is that people think that "ISO" means ISO 8601, whereas it >> actually means ISO 9075. I can see how that's an easy mistake to make, >> though. > > ... especially since we keep referring to 8601 in our own docs. > Does this mean we should do a global s/8601/9075/ in the docs? Negative on the global replace. Some date/time functions legitimately refer to 8601 (see the page on 'extract' for examples). I had thought that to_char/to_timestamp might refer to 8601 for the "ISO week date" feature, but there doesn't appear to be an explicit mention on that page. Perhaps there should be? The text in 8.5.2. Date/Time Output seems to be the culprit here. It (thrice) names 8601 as the governing standard for the ISO output datestyle, and it has some ancillary wording that would become awkward if we just subbed in 9075 instead. Currently the first few sentences read: "The output format of the date/time types can be set to one of the four styles ISO 8601, SQL (Ingres), traditional POSTGRES (Unix date format), or German. The default is the ISO format. (The SQL standard requires the use of the ISO 8601 format. The name of the "SQL" output format is a historical accident.) " I would suggest something like: "The output format of the date/time types can be set to one of the four styles ISO, SQL (Ingres), traditional POSTGRES (Unix date format), or German. The default is the ISO format, which refers to ISO 9075, the SQL standard. (The name of the "SQL" output format is a historical accident, it does not refer to the SQL standard.) " The note I suggested earlier would probably need to change in light of the above, too. Perhaps along these lines: "Note: the output format specified by ISO 9075 is identical to that specified in ISO 8601, except that the uppercase letter 'T' separating the date part from the time part is replaced with a space for the sake of readability." Cheers, BJ
On mån, 2012-05-21 at 15:34 +1000, Brendan Jurd wrote: > I'd be okay with just adding a note in the manual under Date/Time > Output to the effect of "Note: ISO 8601 specifies the use of uppercase > letter 'T' to separate the date and time. Postgres uses a space for > improved readability, in line with other database systems and RFC > 3339." But that is wrong. We use the space because SQL says so. The reason we have all those other formats is for readability or consistency or some secondary standard. But the format of the ISO format is exactly what the SQL standard says, without any other considerations.
Peter Eisentraut <peter_e@gmx.net> writes:
> On mån, 2012-05-21 at 15:34 +1000, Brendan Jurd wrote:
>> I'd be okay with just adding a note in the manual under Date/Time
>> Output to the effect of "Note: ISO 8601 specifies the use of uppercase
>> letter 'T' to separate the date and time. Postgres uses a space for
>> improved readability, in line with other database systems and RFC
>> 3339."
> But that is wrong. We use the space because SQL says so. The reason we
> have all those other formats is for readability or consistency or some
> secondary standard. But the format of the ISO format is exactly what
> the SQL standard says, without any other considerations.
Well, in that case we really need to rewrite the text to not look like
it's citing 8601 as the primary reference. We could replace the <note>
I added with something to the effect that the SQL standard matches 8601
except for not using 'T'.
regards, tom lane
On 24 May 2012 05:30, Peter Eisentraut <peter_e@gmx.net> wrote: > On mån, 2012-05-21 at 15:34 +1000, Brendan Jurd wrote: >> I'd be okay with just adding a note in the manual under Date/Time >> Output to the effect of "Note: ISO 8601 specifies the use of uppercase >> letter 'T' to separate the date and time. Postgres uses a space for >> improved readability, in line with other database systems and RFC >> 3339." > > But that is wrong. We use the space because SQL says so. The reason we > have all those other formats is for readability or consistency or some > secondary standard. But the format of the ISO format is exactly what > the SQL standard says, without any other considerations. > Did you miss my follow-on message on this thread? You are responding to a message that has been superceded. I saw what you wrote earlier, and updated my suggestions for the docs 2 days ago. Please see http://archives.postgresql.org/message-id/CADxJZo34mA54iMgd7RUADCC-R6LQ7w-TA8gqWvahKuA7BSV8vg@mail.gmail.com Cheers, BJ