Ok, some additional remarks:

After playing with the timezone (actually this might have been the first time
after flashing the device and restoring the backup, not sure) both clocks are
synchronous again. So maybe the backup restores the timezone information
incompletely?

However, now my own clock applet displays the wrong time. It essentially does 
  t = time (NULL);
  localtime_r (&t, &time_info);

and currently this seems to yield GMT.

It is perfectly possible that I miss something obvious here, if you have any
insight I'd appreciate hints.

More remarks.

The code I pasted below gives the correct time on the commandline on the device.
However, the equivalent code yields GMT in my own statusbar applet. So *maybe*
the environment within the desktop application is running with a wrong timezone.
I don't understand why the stock desktop clock yields the correct time though.

Does the timezone get set *after* the desktop application got started?

#include <sys/time.h>
#include <time.h>
#include <stdio.h>

int main (int argc, char *argv[])
{
  struct timeval  tv;
  struct tm      *time_info;

  gettimeofday (&tv, NULL);
  time_info = localtime (&tv.tv_sec);

  printf ("%d:%d\n", time_info->tm_hour, time_info->tm_min);

  return 0;
}

Some more remarks...

The Desktop application is messing around with the TZ environment variable. If I
unset() it before determining the time everything works correctly. It seems
there is some mechanism that sets the TZ variable when changing the timezone in
the clock application. Not sure what wents wrong there.

Generally I'd recommend to unset TZ always, this then picks up the system default.

(however, after persisting in unsetting the TZ variable in my clock statusbar
applet the clock application sometimes seems to crash sometimes on setting the
timezone - maybe there is code that relies on a non-NULL TZ environment variable?)

Ah sorry, I mean unsetenv().

Please note that unsetenv("TZ") is different from setting TZ to an empty value,
the latter seems to be interpreted as GMT-Timezone.

Debugging without source code is so much fun...

Something sets the TZ environment variable to values like "8#\x14A" where the
\x14 really is chr (14). That is simply bogus - TZ should be unset so that the
date related functions pick up the timezone configured for the system.
If TZ has to be set (frankly, I don't see a need for that) it should contain
values as described in "man tzset".

After disabling some of the plugins via chmod and checking the value of the
variable, I am pretty confident that the guilty party is the libtn_mail_plugin
for the hildon-navigator. It seems that having this one enabled results in the
broken TZ value.

Please fix this.

Reassigning to the Desktop component, since the wrong TZ value is inside the
desktop application.

Seems the RSS plugin fiddles with TZ as well.

I found that all timezone files in /usr/share/zoneinfo are missing, save
Europe/Helsinki.

Putting the missing files for the US in, and then setting the /etc/localtime
link seems to correct the desktop clock, but not the clocks shown for the "home
city" and "destination city".

I *also* cannot set the "Daylight savings zone" field - has it been deprecated
in favor of actually using the zoneinfo?

*** Bug 457 has been marked as a duplicate of this bug. ***

Still an issue with the latest product image.

Claiming ownership. Bug has been reported to upstream maintainer.

Feature request has been forwarded to upstream maintainer.

This is not an "enhancement" request, the messing with the TZ environment
variable breaks all third party applets that run inside the desktop application.

I have this workaround that works reasonably well, but of course is ugly as
hell. This really should be fixed and I am kind of disappointed by the current
response, given the amount of time I have invested to track this down (and note
that I cannot track this down further, since the newsreader and mail applet are
not open source).

  tz_str = g_strdup (g_getenv ("TZ"));
  g_unsetenv ("TZ");  
  
  gettimeofday (&tv, NULL);
  time_info = localtime (&tv.tv_sec);

  if (tz_str)
    {
      g_setenv ("TZ", tz_str, FALSE);
      g_free (tz_str);
    }

https://garage.maemo.org/tracker/index.php?func=detail&aid=1235&group_id=164&atid=681

Comment 15 Andre Klapper 2008-06-03 14:07:25 UTC

Simon, is this still an issue on the N800 or N810?

[in reply to comment #11]
>  Bug has been reported to upstream maintainer.
could not find an upstream ticket.

It might be fixed - I did not witness this behaviour for a while now. But maybe
I should add the debugging code back to the clock applet again.

Comment 17 Quim Gil 2008-09-02 08:40:34 UTC

Can we resolve this bug now, and reopen if the issue happens to be found still
valid by some other user?

Yeah. Doing so.