Prev: [HACKERS] Missing win32 timezones
Next: [HACKERS] pg_filedump strangeness
From: Magnus Hagander on 9 Apr 2010 07:52
On Wed, Apr 7, 2010 at 00:48, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
> Magnus Hagander <magnus(a)hagander.net> writes:
>> On Wed, Apr 7, 2010 at 00:02, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
>>> Oh, another thought here: what is the effect of the combination of this
>>> with your other proposal to add more timezones to the list?
>

I've applied the patch to add the missing timezone names.

Before I did that I wrote a small perlscript that reads pgtz.c and
compares what's there to what's in the registry of the current
machine. Turns out I had missed one, which is Argentina Standard Time.

This script should probably live in CVS, and be run when Microsoft
releases new timezone data. Where should I put it - src/timezone or
somewhere in src/tools? (it does read pgtz.c in the current directory,
but it doesn't actually edit the file - just outputs on stdout a list
of changes to be made to the file manually)


--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

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

From: Magnus Hagander on 9 Apr 2010 07:58
On Wed, Apr 7, 2010 at 21:06, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
> I wrote:
>>         ereport(LOG,
>>                 (errmsg("could not determine system time zone, defaulting to \"%s\"", "GMT"),
>
> BTW, does anyone remember the reason for making "GMT" nonlocalizable
> in these messages?  It seems more straightforward to do

Nope, can't recall that.


>                (errmsg("could not determine system time zone, defaulting to \"GMT\""),
>
> I suppose we had a reason for doing it the first way but I can't see
> what.  "GMT" seems a fairly English-centric way of referring to UTC
> anyhow; translators might wish to put in "UTC" instead, or some other
> spelling.  Shouldn't we let them?


UTC and GMT aren't actually the same thing. In fact, it might be more
sensible to fall back to UTC than GMT. Both in the message *and* the
code, in that case. They only differ in fractions of seconds, but we
do deal in fractions of seconds... It also carries the nice property
that it's *supposed* to be abbreviated the same way regardless of
language (which is why it's UTC and not CUT).

And either way, it's an abbreviation, and we don't normally translate
those, do we?


--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

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

From: Magnus Hagander on 9 Apr 2010 08:02
On Wed, Apr 7, 2010 at 21:01, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
> Stefan Kaltenbrunner <stefan(a)kaltenbrunner.cc> writes:
>> Even if if keep the current fallback behaviour we should at least fix
>> the windows codepath to do the same as the unix codepath does - as in
>> actually logging that the fallback to GMT happened...
>
> +1 for that anyway.  There already are WARNING messages for the various
> Windows failure cases, but compared to the Unix code
>
>        ereport(LOG,
>                (errmsg("could not determine system time zone, defaulting to \"%s\"", "GMT"),
>        errhint("You can specify the correct timezone in postgresql.conf.")));
>
> they lack either the note about defaulting to GMT or the hint.  I guess
> we should add both of those to the failure cases in the Windows version
> of identify_system_timezone.  Should we also change the WARNING errlevel
> to LOG?  I think the latter is more likely to actually get into the log.

You are suggesting adding this after the "could not find match"
message, correct? Not replacing it? Because if we replace it, we loose
the information of what we failed to match. So basically like
attached?

Also, would LOG be *more* likely to be seen than a WARNING? Why would that be?


--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
From: Tom Lane on 14 Apr 2010 20:54
[ back to this... ]

Magnus Hagander <magnus(a)hagander.net> writes:
> On Wed, Apr 7, 2010 at 21:06, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
>> I suppose we had a reason for doing it the first way but I can't see
>> what. �"GMT" seems a fairly English-centric way of referring to UTC
>> anyhow; translators might wish to put in "UTC" instead, or some other
>> spelling. �Shouldn't we let them?

> UTC and GMT aren't actually the same thing.

Tell it to the zic people --- they are identical except for the zone
abbreviation itself, according to the zic database. There might be some
pedantic argument for preferring the name "UTC", but I'm hesitant to
change that behavior just to satisfy pedants.

> And either way, it's an abbreviation, and we don't normally translate
> those, do we?

I think that might in fact have been the argument for the current coding
style; but it still seems like it's overcomplicating matters in order to
prevent translators from making a decision they should be perfectly
competent to make for themselves. Anyway, it's not real important.
Since nobody else seems to be excited about changing that part,
I'll leave it alone.

regards, tom lane

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

From: Tom Lane on 14 Apr 2010 21:48
Magnus Hagander <magnus(a)hagander.net> writes:
> On Wed, Apr 7, 2010 at 21:01, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
>> ... lack either the note about defaulting to GMT or the hint. I guess
>> we should add both of those to the failure cases in the Windows version
>> of identify_system_timezone. Should we also change the WARNING errlevel
>> to LOG? I think the latter is more likely to actually get into the log.

> You are suggesting adding this after the "could not find match"
> message, correct? Not replacing it? Because if we replace it, we loose
> the information of what we failed to match. So basically like
> attached?

No, I was thinking more like the attached. This changes the Unix code
to separate the info about the fallback timezone into errdetail, and
then makes the Windows messages follow that style.

> Also, would LOG be *more* likely to be seen than a WARNING? Why would that be?

Because that's how log levels sort for the postmaster log. This isn't
an interactive warning --- we will never be executing this code in a
regular backend, only in the postmaster.

regards, tom lane

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: [HACKERS] Missing win32 timezones
Next: [HACKERS] pg_filedump strangeness