On 04/09/14 08:13, Bruce Momjian wrote:
On Thu, May  1, 2014 at 12:09:34PM -0400, Bruce Momjian wrote:
On Thu, May  1, 2014 at 12:33:51PM +1200, Gavin Flower wrote:
On 01/05/14 12:04, Bruce Momjian wrote:
On Thu, May  1, 2014 at 08:27:49AM +1200, Gavin Flower wrote:
On 01/05/14 02:51, Bruce Momjian wrote:
The table of contents for pg_restore -l shows the time the archive was
made as local time (it uses ctime()):

        ; Archive created at Wed Apr 30 10:03:28 2014

Is this clear enough that it is local time?  Should we display this
better, perhaps with a time zone designation?

I think it would be good to include the time zone, as we are all
very international these days - and in Australia, adjacent states
have different dates for the summer time transition!

Personally, I would like to see the date in the format 2014-04-30,
but having the day of the week is good.

Milliseconds might be useful, if you want to check logs files.
OK, I will work on it for 9.5.  Thanks.

So the it would then read something like:

         ; Archive created at Wed 2014-04-30 10:03:28.042 NZST

(but with the correct appropriate time zone designation)?
I think we would use a numeric offset.
I ended up going with the string-based timezone as I was worried that
the sign of the timezone could easily confuse people because the SQL
timezone offset sign is often different from the OS timezone.  The new
output is:

        ;
        ; Archive created at Wed Sep  3 16:12:21 2014 EST   <--
        ;     dbname: test
        ;     TOC Entries: 8
        ;     Compression: -1
        ;     Dump Version: 1.12-0
        ;     Format: CUSTOM
        ;     Integer: 4 bytes
        ;     Offset: 8 bytes
        ;     Dumped from database version: 9.5devel
        ;     Dumped by pg_dump version: 9.5devel

Patch attached.

I would prefer the date in a sane numeric format to the left of the time (similar to what I suggested above), easier to sort (if a sort is required) - it is also easier to use regular expressions to select statement in an arbitrary date/time range.

I don't always know in advance that I need to debug something, so I tend to try and ensure that the relevant data is easy to find, even when I currently don't expect ever to do so. This is a lesson that I have learnt from over 40 years of commercial programming experience using a variety of languages on a wide range of platforms.

Most likely, I will never need to worry about the precise format of Archive statement output, but ...


Cheers,
Gavin



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to