1 (edited by piersoar 2008-10-09 01:25:34)

Topic: Clock fails (AU) DST change

Possibly a bug, or just a problem 'down-under'?

Australia has just moved to Summertime - and neither of my Chumbys responded to it without manual intervention.

Have a 2.8.8 BETA and a 2.7.16 on Melbourne time with 'Set time from the Internet' checked.
Both stayed on Wintertime until I reselected the timezone.

Is there perhaps a trigger that's set against mainstream Northern Hemisphere DST changes? (Realise we're not 'official' down here yet, but everything else works great!)

Didn't cause me any problems but with most of you moving from summertime shortly and the chance to test DST changes only happening a couple of times a year figured this might be valuable feedback.

Cheers,  Andrew

Re: Clock fails (AU) DST change

The timezone files are part of the operating system, and therefore part of the firmware, not the Control Panel.

We try to pull the latest files for Linux from the appropriate place, but occasionally a country will change their timezone rules at a time that doesn't mesh with our release schedule.  In this case, it appears that Australia recently changed their DST rules.

Could you please post the software and firmware versions that you're currently running on your chumby (they can be found on the Contrlol Panel->Settings->Chumby Info screen).

Re: Clock fails (AU) DST change

Doing more research, it appears this year is quite a mess in AU with the DST switch. Apparently, only *some* states in AU are switching three weeks early this year, while the rest are still using the old rules.  Telstra sent out a release noting that many of their devices are failing the switchover, and I've found technotes for *many* devices that are experiencing the same issue.

It's possible that you might get a proper switch if you try other cities that might have picked up the new timezone rules - I think we support 8 or 9 AU cities in different states. In the meantime, we'll have QA see what they can figure out.  We actually did a full regression of the time zone subsystem comparing the behavior against a full up-to-date Linux desktop system and passed, so it's not just us.

We checked with NIST and found that a new timezone file was posted just this morning.

I'm not sure why Australia likes to change time zone rules in such a chaotic fashion - it's very disruptive.

Sorry about the problem.

4 (edited by piersoar 2008-10-09 01:24:55)

Re: Clock fails (AU) DST change

Thanks Duane

Almost every other clock in the house had to be manually adjusted so these couple of extras were no big deal (and actually much simpler than many to change wink).

Given that just reselecting the city 'Melbourne' under the 'set time zone' page (it is one of the cities you support) caused them to update correctly to Summer time, do you think it is bad timezone data?

Software is at 1.6.0 and Firmware is 733 - on both Chumbys.

Ubuntu boxes updated to DST just fine although, as you noted from NIST, they also received a timezone data update on the Tuesday after the change here.

(Won't comment on the fiasco of 5 timezones moving at several different times here - but the changes this year are designed to further reduce the confusion roll)

Cheers,  Andrew

Re: Clock fails (AU) DST change

OK, thanks for the info - it does look like it was bad timezone data from NIST, since we validated properly against a desktop machine running exactly the same data.

We typically pull the latest data just before we do a firmware update, however in this case apparently it didn't help - there have been seven versions published so far this year and whichever one fixed this must have come out after 733 was frozen.

Unfortunately our update process doesn't allow updates of single files, so we can't publish them as frequently as a desktop Linux distro.

One of our Customer Service guys, Matt, is an Aussie - he filled me in on the rather peculiar situation with AU timezones.