Alpha Clock Five - GPS & DST support & more

[wbp]

I guess I'm a "Clockaholic" now. I saw the Alpha Clock Five at Adafruit and decided I had to order one. (funny aside - it turns out that EMSL is just a few miles from me, but I didn't know that when I ordered the kit, and besides I like to support Adafruit)

So of course I had to dig into the firmware and customize it... So far I've fixed a few bugs, added support for the Adafruit "Ulimate GPS", added automatic DST setting (US only for now), and a couple of other features. With these mods and a GPS module you've got a clock that never needs to be set.

Windell has already picked up the bug fixes and put them in the "official" firmware.

If anyone wants to play with this, I've posted it on GitHub at https://github.com/wbphelps/AlphaClock

Keep in mind that this is a work in progress, there are likely to be frequent updates.

William

[odometer]

About the time zone offsets: it seems that time zones UTC+13h and UTC+14h exist.

Also, how does "time zone minutes" work? If "time zone hours" is -3 and "time zone minutes" is 30, will that give me UTC-3h30min or UTC-2h30min?

How does the Daylight Saving stuff work? In my code, I just check once a day for DST adjustments, and it works as a display hack: all year round, the clock's internal timekeeping is in "winter" time.

Do you have code to make sure that, on the night clocks are to be set back 1 hour, that the time does not get stuck in a loop repeating that one hour endlessly? I mention this because I have heard of an operating system with this exact bug.


If you want a real challenge, program in Daylight Saving rules for Brazil: the DST rule there invokes the Easter computus!

[wbp]

Yeah, I should actually have known that TZ hour can be as high as +14, I was sailing in Kiribati a couple of years ago. Easily fixed.

Time Zone Minutes uses the same sign as Time Zone Hours. I've really no idea which way is better but that's the usual algorithm.

I check DST once a minute. You can check less often but then you have to wait for the adjustment to happen if you just built your clock or it was reset for some reason. The code is written with a flag set such that the adjustment is only done once a day, which keeps it from looping between 2 am and 1 am at the end of DST. It also handles southern hemisphere, where DST starts in a later month than it ends.

If you don't adjust the time when DST starts or ends, what happens if you unplug your clock to move it (or the power fails) and then plug it back in again? Wouldn't the time be wrong until the next time your code checks it?

There are other problems with the DST adjustment for Brazil - they do it at midnight! So your clock gets to 16 February 2013 23:59:59, then 1 second later jumps back to 23:00:00 on the same day. I have not tested my code to see if it can handle that, but it might.

William

[odometer]

Time Zone Minutes uses the same sign as Time Zone Hours. I've really no idea which way is better but that's the usual algorithm.

Zero is (mathematically) neither positive nor negative. So... if Time Zone Hours are 0 and Time Zone Minutes are 30, what then?

If you don't adjust the time when DST starts or ends, what happens if you unplug your clock to move it (or the power fails) and then plug it back in again? Wouldn't the time be wrong until the next time your code checks it?

I live in Connecticut. Here, in the winter we use UTC-5h (henceforth referred to as "winter timekeeping"). In the summer, we use UTC-4h (henceforth referred to as "summer timekeeping").
My clock's Chronodot uses winter timekeeping the whole year round.
The software to display the time and date never ever displays anything without first checking if Daylight Saving Time is currently in effect. If it is in effect, then the software does the arithmetic to convert to summer timekeeping for display; otherwise, the winter timekeeping is displayed unchanged.
Calendar stuff is hard and is only recalculated upon a change of date, that is when winter timekeeping starts a new day, and/or seasonally appropriate local timekeeping starts a new day.

Please take a look at what I have running on my clock, attached here.
(please change file extension to .pde)
Note: my code for the alarm is buggy around Daylight Saving Time changes; I don't really care enough to fix it.

[wbp]

I am not aware of any countries that would have a time zone offset of only minutes. It's theoretically possible but so what?

It makes no sense to me to keep the RTC in standard time. Either keep it in current local time or UT. If it's not in local time the program has to compute local time in several places (alarm check, clock setting, time display). What's the point in doing all that? If you like doing it feel free but I sure don't see any advantage in doing it this way.

I can see some argument for keeping the RTC in UT, since that is what any time sync service is going to use (GPS, WWV, etc). But again, doing this means recomputing the local time in 3 places, and I don't see the point.

[odometer]

It makes no sense to me to keep the RTC in standard time. Either keep it in current local time or UT. If it's not in local time the program has to compute local time in several places (alarm check, clock setting, time display).

The code has separate, global variables for "standard time" and "displayed time". This is for just the reason you mention: it would be a bit awkward to recalculate the same thing in so many places. The "displayed time" is used to display the time, both during normal timekeeping and in time-setting mode. The alarm code refers to the "displayed time" to know when to start making noise.

If you think about it, daylight saving time is a display hack.


As for your code: what happens if there is no power to the clock during a DST transition? Where I live, I get a lot of power outages, so this is a real issue.