Thank you Marijn. I have done as you suggest; specify the
server
timezone in webmail.ini as EADT and made sure that
auto_timezone is
enabled. This seems to have worked.
Also, thanks for the thorough explanation.
Cheers,
Geoffrey
On 27/11/2007 3:29 PM, Surgemail Support (Marijn) wrote:
> The relevant timezone codes you can explicitly set the
webmail timezone
> to are:
> WAST or WADT = West Australian Standard / Daylight
> CAST or CADT = Central Australian Standard / Daylight
> EAST or EADT = Eastern Australian Standard / Daylight
>
> The following may also still be helpful for you,
although it looks to me
> like you have already covered that... Let me know how
you go thanks.
>
> Marijn
>
> From: "Surgemail Support (Marijn)"
<surgemail-support netwinsite.com>
> To: <surgemail-listnetwinsite.com>
> Sent: Friday, June 22, 2007 8:48 AM
> Subject: Re: [SurgeMail List] Odd Time problem only
webmail
>
>
> > OK a heads up on this one for everyone struggling
with timezone "off by
> > one"
> > problems in webmail... I have confirmed a webmail
timezone bug as
> follows
> > and suspect it has been responsible for the
occasional reports I
> mentioned
> > in previous email.
> >
> > Webmail can indeed do it's timezone detection
wrong. With a two fold
> > result:
> > - most significantly message display seem out by
one hour as they are
> > displayed in the wrong timezone
> > - date header contains the correct time in the
wrong timezone (not a
> very
> > visual bug as the date itself is actually
correct)
> > This is due to a fault in the serverside timezone
detection routine
> during
> > daylight savings time. This affects all platforms
but only when using
> the
> > "server" timezone in webmail.ini. Let
me explain what is going on.
> The logic
> > used to determine which timezone to display
messages in is kinda
> complicated
> > and dependant on the following settings:
> >
> > webmail.ini:
> > timezone: with valid values: browser / server
(default) / letter
> based zone
> > (eg mst) / number based zone (eg -700)
> > auto_timezone: with valid values true (default) /
false
> > user.dat:
> > timezone: {setting missing} (default) / browser /
letter based timezone
> > _auto_timezone: {setting missing} (default) /
true / false
> > gmt_mins: number based timezone (automatically
updated on login)
> >
> > Webmail determines the timezone by:
> > starting with webmail.ini timezone
> > then applying user.dat timezone (if it exists)
> > if applicable, use auto_timezone (possibly
overridden with
> > _auto_timezone) combined with gmt_mins to
automatically switch timezones
> > based correct for daylight savings changes.
> >
> > Now in the event that webmail.ini timezone is set
to server and
> user.dat has
> > no timezone setting, webmail will use the server
timezone. It
> receives this
> > as a numeric non daylight value which it is not
able to apply the
> webmail
> > auto_timezone daylight savings correction to, so
messages are
> displayed in
> > the non daylight server timezone. This is the
default for newly created
> > accounts unfortunately.
> >
> > The reason why the problem seems to mostly
"disappear" is as follows. As
> > soon as someone presses save on the webmail
personal profile page
> then the
> > user.dat file receives a value for timezone. The
only settings in the
> > timezone dropdown are browser or a specific
letter based timezone. In
> any
> > of
> > these cases the fault will no longer be apparent
as the server
> timezone is
> > no longer used and the timezone will be correctly
switched at each
> > daylight
> > savings transition.
> >
> > Also if a letter based timezone is specified in
webmail.ini the same
> > holds,
> > the auto_timezone code will correctly switch
between daylight and non
> > daylight times when appropriate and the zone that
webmail uses will
> always
> > seem correct.
> >
> > This is a bug that needs fixing but as there are
easy workarounds, at
> this
> > stage I need to further investigate specifically
where to fix it so I
> do not
> > break something else and complicate the problem
further. If this bug is
> > causing problems for you my recommendation is to
explicitly specify the
> > server timezone in webmail.ini and make sure that
auto_timezone is
> > enabled.
> > This should mean that you never have to touch the
timezone during
> daylight
> > savings switches etc and webmail timezone
detection is correct for all
> > webmail users.
> >
> > Anyway, let me know if anyone has any
observations to the contrary 
> >
> > Marijn
>
>
>
>
>
>
> surgemail-listnetwinsite.com wrote:
>> Hi-
>>
>> Our Webmail time did not change when we moved to
Daylight Savings time
>> in NSW. Thus it is now 1 hour slow.
>>
>> Currently webmail.ini contains the following
lines:
>>
>> timezone server
>> auto_timezone true
>> enable_browser_timezone true
>>
>> tried doing the following but to no affect:
>> timezone Australia/NSW
>> OR
>> time_offset +100
>>
>>
>> How do I fix this when the only parameter that
seems to do anything is
>> 'timezone server'?
>>
>> Many thanks,
>> Geoffrey
>>
>>
>
>
>
|
