Timestamp docs weirdness

Christopher Kings-Lynne writes:

What in the heck is 'zulu', 'allballs' or 'z'???

'allballs' probably alludes to the visual appearance of '00:00:00'. 'z'
and 'zulu' should be time zones equivalent (or similar?) to UTC or GMT
((US?) military jargon).

--
Peter Eisentraut peter_e@gmx.net

What in the heck is 'zulu', 'allballs' or 'z'???

'allballs' probably alludes to the visual appearance of '00:00:00'. 'z'
and 'zulu' should be time zones equivalent (or similar?) to UTC or GMT
((US?) military jargon).

But they don't work...

Chris

Hello Christopher,

Wednesday, October 22, 2003, 10:21:02 AM, you wrote:

What in the heck is 'zulu', 'allballs' or 'z'???

'allballs' probably alludes to the visual appearance of '00:00:00'. 'z'
and 'zulu' should be time zones equivalent (or similar?) to UTC or GMT
((US?) military jargon).

But they don't work...

Only the combination of both doesn't work:
template1=# select 'allballs'::timetz;
timetz
-------------
00:00:00+00
(1 row)

template1=# select '0:0:0 z'::timetz;
timetz
-------------
00:00:00+00
(1 row)

template1=# select '0:0:0 zulu'::timetz;
timetz
-------------
00:00:00+00
(1 row)

template1=# select 'allballs'::timetz;
timetz
-------------
00:00:00+00
(1 row)

template1=# select 'allballs z'::timetz;
ERROR: Bad time external representation 'allballs z'
template1=# select 'allballs zulu'::timetz;
ERROR: Bad time external representation 'allballs zulu'

Your problem is using 'time' which doesn't know time zones.

--
Best regards,
Marcus mailto:mail@marcus-boerger.de

Here is a documentation patch that makes it all more consistent.

Chris

Marcus Bï¿œrger wrote:

'allballs' probably alludes to the visual appearance of '00:00:00'. 'z'
and 'zulu' should be time zones equivalent (or similar?) to UTC or GMT
((US?) military jargon).

Why do we support just 'zulu' and none of the other magic time zone names:

http://wwp.greenwichmeantime.com/info/timezone.htm

Chris

Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:

Why do we support just 'zulu' and none of the other magic time zone names:
http://wwp.greenwichmeantime.com/info/timezone.htm

AFAIK, zulu is the only one of those "military" designations that has
any currency at all. I don't feel a strong need to import the rest
... particularly not the single-letter versions; the presence of those
would allow the system to accept many typos :-(

The real answer to all such questions, though, is that we ought not have
the set of known timezone names locked down in code at all. It should
come from a user-alterable configuration file. This would let us get
rid of "australian_timezones" as well as solve the perennial gripes from
out-of-the-way places that their favorite local zone name isn't
recognized.

regards, tom lane

Patch applied. Thanks.

---------------------------------------------------------------------------

Christopher Kings-Lynne wrote:

Here is a documentation patch that makes it all more consistent.

Chris

Marcus B?rger wrote:

Hello Christopher,

Wednesday, October 22, 2003, 10:21:02 AM, you wrote:

What in the heck is 'zulu', 'allballs' or 'z'???

Index: doc/src/sgml/datatype.sgml
===================================================================
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/datatype.sgml,v
retrieving revision 1.126
diff -c -r1.126 datatype.sgml
*** doc/src/sgml/datatype.sgml	16 Oct 2003 04:52:21 -0000	1.126
--- doc/src/sgml/datatype.sgml	22 Oct 2003 09:02:10 -0000
***************
*** 1573,1582 ****
<entry><literal>04:05 PM</literal></entry>
<entry>same as 16:05; input hour must be <= 12</entry>
</row>
- 	 <row>
- 	  <entry><literal>allballs</literal></entry>
- 	  <entry>same as 00:00:00</entry>
- 	 </row>
<row>
<entry>04:05:06.789-8</entry>
<entry>ISO 8601</entry>
--- 1573,1578 ----
***************
*** 1627,1632 ****
--- 1623,1636 ----
<entry>-8</entry>
<entry>ISO-8601 offset for PST</entry>
</row>
+ 	 <row>
+ 	  <entry>zulu</entry>
+ 	  <entry>Military abbreviation for GMT</entry>
+ 	 </row>
+ 	 <row>
+ 	  <entry>z</entry>
+ 	  <entry>Short form of zulu</entry>
+ 	 </row>
</tbody>
</tgroup>
</table>
***************
*** 1828,1834 ****
<entry>midnight yesterday</entry>
</row>
<row>
! 	  <entry><literal>zulu</>, <literal>allballs</>, <literal>z</></entry>
<entry><type>time</type></entry>
<entry>00:00:00.00 UTC</entry>
</row>
--- 1832,1838 ----
<entry>midnight yesterday</entry>
</row>
<row>
! 	  <entry><literal>allballs</literal></entry>
<entry><type>time</type></entry>
<entry>00:00:00.00 UTC</entry>
</row>

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

OK, do we want to put back the mention of these in the release notes?
The non-zulu ones sound pretty strange to me and might be better left
undocumented.

---------------------------------------------------------------------------

Marcus B?rger wrote:

Hello Christopher,

Wednesday, October 22, 2003, 10:21:02 AM, you wrote:

What in the heck is 'zulu', 'allballs' or 'z'???

'allballs' probably alludes to the visual appearance of '00:00:00'. 'z'
and 'zulu' should be time zones equivalent (or similar?) to UTC or GMT
((US?) military jargon).

But they don't work...

Only the combination of both doesn't work:
template1=# select 'allballs'::timetz;
timetz
-------------
00:00:00+00
(1 row)

template1=# select '0:0:0 z'::timetz;
timetz
-------------
00:00:00+00
(1 row)

template1=# select '0:0:0 zulu'::timetz;
timetz
-------------
00:00:00+00
(1 row)

template1=# select 'allballs'::timetz;
timetz
-------------
00:00:00+00
(1 row)

template1=# select 'allballs z'::timetz;
ERROR: Bad time external representation 'allballs z'
template1=# select 'allballs zulu'::timetz;
ERROR: Bad time external representation 'allballs zulu'

Your problem is using 'time' which doesn't know time zones.

--
Best regards,
Marcus mailto:mail@marcus-boerger.de

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

OK, do we want to put back the mention of these in the release notes?
The non-zulu ones sound pretty strange to me and might be better left
undocumented.

What's there to go in the release notes? We haven't changed any code,
and zulu is the only 'named' timezone we support (from checking source
code).

I've just reorganised the docs, so that it's actually explained what
they are.

Chris

Oh, OK, sounds like we are good.

---------------------------------------------------------------------------

Christopher Kings-Lynne wrote:

OK, do we want to put back the mention of these in the release notes?
The non-zulu ones sound pretty strange to me and might be better left
undocumented.

What's there to go in the release notes? We haven't changed any code,
and zulu is the only 'named' timezone we support (from checking source
code).

I've just reorganised the docs, so that it's actually explained what
they are.

Chris

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

OK, do we want to put back the mention of these in the release notes?
The non-zulu ones sound pretty strange to me and might be better left
undocumented.

AFAICS the updated docs are correct. Since the code behavior has not
changed, there is no need for a release-notes entry, is there?

Only the combination of both doesn't work:
template1=# select 'allballs zulu'::timetz;
ERROR: Bad time external representation 'allballs zulu'

That's because 'allballs' is defined as '00:00:00 UTC', that is,
it already defines a timezone. The above is a double specification
of timezone and gets the same error as

regression=# select '00:00:00 UTC UTC'::timetz;
ERROR: invalid input syntax for type time with time zone: "00:00:00 UTC UTC"

I see no bug here.

regards, tom lane