Re: wrong interpretation of timezone information
On Mon, 2010-05-10 at 16:48 +0100, Lukas Zeller wrote:
> Hi Patrick,
> On May 10, 2010, at 9:04 , Patrick Ohly wrote:
> > Confirmed, works for me.
> > I should have mentioned that I had already made similar changes as you
> > on the moblin.org master branch (check for NULL obj in debug macros,
> > enable debug logging inside vtimezone code when invoked by mimedir
> > profile parser).
> > My own debug logging patches go a bit further:
> > - log an error when parsing a VTIMEZONE fails
> > - logging of libical timezone conversion
> > - logging of timezone matching
> > I'm trying to track down an unexpected timezone failure with this which
> > occurs when normal Evolution events are involved.
> > Do you agree with these changes? Would you mind merging them? I rebased
> > them on your "luz" branch.
> The attempt to init the time zones after reading config (fc000b0f45
> (TSyncAppBase: moved system time zone parsing after config reading))
> creates a chicken and egg problem. The config reading process relies
> itself on the time zone stuff being initialized, most prominently for
> <definetimezone>, but also for other tags that have ISO8601 timestamp
> Maybe the dilemma can be solved by adding an optional, second
> initialize run after config reading that can be switched on
> specifically to track down timezone init problems.
That would imply redoing some of the work. What about the following
(code in master, as I need to fix that anyway):
Author: Patrick Ohly <patrick.ohly@...>
Date: Tue May 11 16:57:35 2010 +0200
time zone init and logging: split into part before and after config parsing
This patch reverts the "move system time zone parsing after config
reading" part of commit fc000b0f45. As Lukas pointed out, config parsing
already depends on time zones, for example for <definetimezone>.
But this patch keeps the finishConfig() callback and uses it to invoke
a second global time zone function. On Linux, that function is used
to add the libical time zone definitions and logs them at the same time.
Builtin time zones are added at the original time, before parsing the
This is a compromise between having no time zones while parsing the config
and not logging the libical time zones. It works for SyncEvolution, because
it doesn't reference the additional time zones in the config.
> Another option would be to use the ConferrPuts() channel, which is
> ready before config is read by definition.
That won't help, because I need this information in the normal log file
to simplify remote debugging.
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.