Windows Mobile system clock in a time zone of its own

March 31, 2009

Vista busy cursor For weeks now I have grown quite used to my phone changing ringtone automatically every day, using the method described in detail here.

It was distinctly odd, then, when on business in London yesterday (which was a Monday)  my phone rang with the Daily Giz Wiz lazy Sunday theme. That was the first time my perfect system had broken down. Not tragic, but I wanted to know what had gone wrong; more from a technology standpoint than anything else.

The daily ringtone system involves use of a third party scheduler program which, every night at 1 minute after midnight, runs my home-grown theme switcher program, DailyRingTone.exe.  The latter updates the currently selected ringtone setting in the Windows Registry to whichever theme file out of Sunday.mp3, Monday.mp3, Tuesday.mp3, etc corresponds to the current day of the week as reported by the system clock.

The scheduler was still up and running. The switcher program was still there.  I ran the switcher program manually and it did change the ringtone to Monday’s theme.

I decided to see what would happen that night at midnight. Checking a few minutes after midnight I found that the ringtone was still set to Monday.  Another failure then.  So I manually changed the ringtone to a totally different music file then manually ran the theme-switching program, DailyRingTone.exe. It had switched the ringtone back to Monday’s theme even though it was now 10 past midnight on the morning of Tuesday.

Maybe something to do with the clocks having been advanced one hour on Sunday night from GMT to BST?  My phone was telling me it was Tuesday but could some of the internal systems still be on GMT, so under the misapprehension that it was still 23:10 on Monday?

As an experiment I changed the event timer on the scheduler from 00:01 to 01:01 and went to bed.  This morning I checked the ringtone and found it had been set correctly to the Tuesday theme.  This seems to bear out my theory that the system clock is still one hour behind when determining the date for purposes of reporting the current day of the week.  Windows Mobile does not adjust automatically for daylight saving time, you have to move the time on manually.  Maybe it keeps tabs separately on the original time setting and the adjusted setting.  If I could be bothered I’d write a short app to investigate further.

Meantime, I am just going to leave the scheduler set on 1 minute past 1am, to make sure the phone has definitely registered the arrival of a new day before the ringtone switching program runs.  So during the summer months, while we’re on British Summer Time, if anyone rings me after midnight and before 1am I’ll get the wrong ringtone.

I guess I’ll just have to live with that.

AddThis Social Bookmark Button



  1. I’ve Googled around the issue a bit and now conclude that in all innocence I used the wrong time function in my code.

    I used the GetSystemTime function, not twigging to the fact that there is also GetLocalTime which takes account of adjustments for local time zone and daylight savings. GetSystemTime picks up an underlying system time which is supposed to represent GMT regardless.

    So it’s a bug. Programmer failure. I had only failed to spot the problem because until the weekend my local time happened to coincide with system time given that I am in the UK where we use unadulterated GMT during the winter. Anyone trying to use my program in the US must have been getting very confusing results.

    At least the problem is easy to fix. I have now changed the one function call, recompiled and replaced the file on drop.io, login password = dickyde.


  2. I had something vaguely similar when I first installed XP on my MacBook using Bootcamp; every time I booted into XP, it knocked the system clock an hour out, and I had to reset it manually when I wanted to use Mac OS X. Apparently, OS X kept the system clock constantly set to GMT, and applied an offset to get the correct time displayed on the bar; XP on the other hand set the system clock to local time. Or maybe it was the other way round; it makes my head spin thinking about it! Apple ended up releasing a fix in one of the subsequent OS X upgrades, so the problem just went away in the end.

    I just mention it because it sounds like it could be something vaguely similar. I’m sure all your techy readers will come along and tell me how wrong I am, though … 😛

    • Thanks Jonny. Maybe I’m not going mad then.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: