On Thu, Apr 15, 2010 at 3:48 AM, Tom Lane wrote:
> Magnus Hagander writes:
>> On Wed, Apr 7, 2010 at 21:01, Tom Lane 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_syste
On Thu, Apr 15, 2010 at 2:54 AM, Tom Lane wrote:
> [ back to this... ]
>
> Magnus Hagander writes:
>> On Wed, Apr 7, 2010 at 21:06, Tom Lane 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
>>>
Magnus Hagander writes:
> On Wed, Apr 7, 2010 at 21:01, Tom Lane 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
[ back to this... ]
Magnus Hagander writes:
> On Wed, Apr 7, 2010 at 21:06, Tom Lane 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
On Wed, Apr 7, 2010 at 21:01, Tom Lane wrote:
> Stefan Kaltenbrunner 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 a
On Wed, Apr 7, 2010 at 21:06, Tom Lane 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 straigh
On Wed, Apr 7, 2010 at 00:48, Tom Lane wrote:
> Magnus Hagander writes:
>> On Wed, Apr 7, 2010 at 00:02, Tom Lane 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 th
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
(errmsg("could not determ
Stefan Kaltenbrunner writes:
> yeah that is one aspect - and in talking to the OP he would have
> prefered the database not starting up at all, logging an error and a
> hint on setting a fixed timezone in the conf.
Well, you started from the statement that this was an embedded copy
of postgres
Magnus Hagander wrote:
On Wed, Apr 7, 2010 at 7:04 PM, Robert Haas wrote:
On Wed, Apr 7, 2010 at 12:20 PM, Stefan Kaltenbrunner
wrote:
Tom Lane wrote:
Stefan Kaltenbrunner writes:
hmm all that code makes me wonder a bit about a more general issue - is
the "fallback to GMT if we fail to act
On Wed, Apr 7, 2010 at 7:04 PM, Robert Haas wrote:
> On Wed, Apr 7, 2010 at 12:20 PM, Stefan Kaltenbrunner
> wrote:
>> Tom Lane wrote:
>>>
>>> Stefan Kaltenbrunner writes:
hmm all that code makes me wonder a bit about a more general issue - is
the "fallback to GMT if we fail to ac
On Wed, Apr 7, 2010 at 12:20 PM, Stefan Kaltenbrunner
wrote:
> Tom Lane wrote:
>>
>> Stefan Kaltenbrunner writes:
>>>
>>> hmm all that code makes me wonder a bit about a more general issue - is
>>> the "fallback to GMT if we fail to actually make sense of the right imezone
>>> to use" actually a
Tom Lane wrote:
Stefan Kaltenbrunner writes:
hmm all that code makes me wonder a bit about a more general issue - is
the "fallback to GMT if we fail to actually make sense of the right
imezone to use" actually a good idea?
What alternative are you proposing? Failing to start the server does
Stefan Kaltenbrunner writes:
> hmm all that code makes me wonder a bit about a more general issue - is
> the "fallback to GMT if we fail to actually make sense of the right
> imezone to use" actually a good idea?
What alternative are you proposing? Failing to start the server doesn't
seem like
Magnus Hagander wrote:
On Wed, Apr 7, 2010 at 00:48, Tom Lane wrote:
Magnus Hagander writes:
On Wed, Apr 7, 2010 at 00:02, Tom Lane 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?
[ none ]
Ah, right
On Wed, Apr 7, 2010 at 00:48, Tom Lane wrote:
> Magnus Hagander writes:
>> On Wed, Apr 7, 2010 at 00:02, Tom Lane 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?
>
>> [ none ]
>
> Ah, right, I hadn
Magnus Hagander writes:
> On Wed, Apr 7, 2010 at 00:02, Tom Lane 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?
> [ none ]
Ah, right, I hadn't looked closely at the logic before. Still have
two co
On Wed, Apr 7, 2010 at 00:02, Tom Lane 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? In
> particular, what happens if we use the extended list in an unpatched
> system that doesn't know about those ne
Oh, another thought here: what is the effect of the combination of this
with your other proposal to add more timezones to the list? In
particular, what happens if we use the extended list in an unpatched
system that doesn't know about those new zone names? I'm wondering
if we *have* to make this
Magnus Hagander writes:
> On Tue, Apr 6, 2010 at 23:44, Tom Lane wrote:
>> I'm not clear on this. Would this patch fix a real seen-in-the-field
>> condition, or is it speculative? In particular, if the loop had kept
>> going in the complainant's machine, would it have found another entry
>> tha
On Tue, Apr 6, 2010 at 23:44, Tom Lane wrote:
> Magnus Hagander writes:
>> When diagnosing a problem for a guy in the german channel (with Stefan
>> as mediator :P), we've found a case where the timezone information in
>> the registry seem to be empty for some timezones. The current timezone
>> m
Magnus Hagander writes:
> When diagnosing a problem for a guy in the german channel (with Stefan
> as mediator :P), we've found a case where the timezone information in
> the registry seem to be empty for some timezones. The current timezone
> matching code will abort scanning when it comes across
When diagnosing a problem for a guy in the german channel (with Stefan
as mediator :P), we've found a case where the timezone information in
the registry seem to be empty for some timezones. The current timezone
matching code will abort scanning when it comes across one of these,
thus claiming it c
23 matches
Mail list logo
