Thread: External Open Standards

External Open Standards

From
Simon Riggs
Date:
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


Re: External Open Standards

From
Peter Eisentraut
Date:
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.



Re: External Open Standards

From
Daniel Farina
Date:
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


Re: External Open Standards

From
Brendan Jurd
Date:
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


Re: External Open Standards

From
Daniel Farina
Date:
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


Re: External Open Standards

From
Tom Lane
Date:
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


Re: External Open Standards

From
Peter Eisentraut
Date:
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.



Re: External Open Standards

From
Tom Lane
Date:
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


Re: External Open Standards

From
Brendan Jurd
Date:
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


Re: External Open Standards

From
Peter Eisentraut
Date:
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.



Re: External Open Standards

From
Tom Lane
Date:
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


Re: External Open Standards

From
Brendan Jurd
Date:
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