Daylight savings correction.....

[JAM2014]

Hi All,

I'm looking for ideas on how best to implement a strategy to add daylight savings time correction to an existing clock project. This clock consists of a PIC, an RTC (DS3231), and an GLCD display. The time/date is set with three pushbuttons and a simple menu system. In concept this is an easy task, but some of the details might become a bit messy if not handled correctly. I'm trying to formulate the logic that will get this task done seamlessly. I've already got working code that allows me to calculate the day in March that daylight savings begins, and the day in November that it ends. Now, I need to use this information to intelligently maintain the correct time.

I want the user to be able to set the clock to the current local time whether it's standard time or daylight time. From this point forward, I then want the clock to automatically adjust the time as necessary to compensate for daylight savings.

My plan is to have the time/date menu system set the RTC with the current time/date & set a boolean flag, 'bIsDST', in EEPROM to keep track of whether the currently stored RTC time represents daylight time or not. Then, at each subsequent time transition, the code will add/subtract one
hour from the RTC time & set the bIsDST flag as appropriate.

Does this scheme sound like it will get the job done? It seems like it will, but I don't want to under/over-think the problem!

Thanks!

Jack

[temtronic]

It sounds good 'on paper', try it,.. but I'd use the battery backed RAM of the RTC module, at least for test purposes. It's faster, never wears out (in case of a code booboo) and simple to cut code for.
Jay

[PCM programmer]

[Ttelmah]

The normal way to do this is to Have the clock itself not change, but work in UTC. Then as PCM_programmer says just turn on the DST flag in March, and off in November. Ideally store just two UTC offsets. The one for 'winter' time (so the local time zone), and the one for 'summer'. This way you can cope with situations where the DST is not just one hour. Historically some countries did try 2 hour DST. Don't know if any do at present, but it is worth having the system able to cope. If the flag is 'on', you add the winter offset, if 'off' the summer offset.

[temtronic]

Yeah DST isn't 'standard' ( no pun ). Here in Canada, Newfoundland is 1/2hr off..and some areas don't observe DST.
The problem I've had over the years is 'they' changed the dates for DST 2 or 3 times since the late 70s. Original RTC chips like the DS1287 had the dates 'burned in' and could change automatically. Nowadays theres a huge Windows program in every PC that does what we can do in 4-5 lines of PIC code !
A benefit of using UTC is your code is easliy transportable to other countries or if you use a GPS sat to 'sync' your RTC to.

Jay

[RF_Developer]

I have a nixie tube clock at home. Built from a kit. Took all of half an hour to put together. Nice little thing :-) I've got the optional GPS synchroniser.

The solution the clock designer adopted was simple: all these problems of different places changing by different amounts at different dates is a big problem. So it has a simple push button on the back that you press to manually select savings mode. Only need to press it twice a year (in most places). In countries that don't have daylight savings you don't have to press it at all. The rare places with half and two hours offsets just have to lump it, and in truth wouldn't be buying it anyway as the supplier is a UK one-man-band and so they are probably only going to the UK and a few European countries.

Simple is often better. Implementing the locallised change dates and offsets is simple but complex if "properly" implemented. PCs can do it because they have all that locallisation provided with the OS and have access to updates for any changes.

I do remember doing a radar remote sampling system which worked exclusively in UTC (no savings). It had a GPS card and a Windows clock sync application called Tardis (its still going apparently: http://www.mingham-smith.com/tardis.htm). It fell over for a week in March 2000 as it was using the DOS daylight savings API/code that turned out to give a different change date from the Windows (at that time was still using 95) daylight savings code. It was a real mess for a week, after which it came back into synchronisation. That went down as a Y2K bug of sorts.

[temtronic]

NIXIEs !!! nice, I rememeber them...zappp.... and 'line of NE2' digital readouts and ,sigh fixin ASR-33s.

I still have some 5 volt, 7 segment INCANDESCENT DIP pkg displays around here ...'somewhere'.

I also 'upgraded' the monodigichron to a PIC18F46K22 and 8by12 LED display. kinda overkill but 46K22s are always nearby !
Jay

[RF_Developer]

[temtronic]

7442 I think is the high voltage BDC> 0-9 pin output.
guess I should have saved all my NIXIE tubes.....$$$
Jay

[JAM2014]