Is there an easy way to implement daylight saving changes?

My take would be that it depends almost entirely on the undisclosed nature of the product. If it's a consumer grade item (digital camera, microwave oven, automatic thermostat) don't bother, just make it easy for the end user to set their desired time. If it's for something where the time really matters, use UTC unless there are similar products and/or a common expectation in the target community for a specific time model. Also, leap seconds.

Once you go down the path of automatically correcting for DST, you'll need to give the end user the ability to apply updates to the rules. Not having automatic DST changes is a very minor annoyance, since that is how most consumer grade products behave. On the other hand, having the time change incorrectly (and unexpectedly) is much worse.

--
Rich Webb     Norfolk, VA

Agree with Rich. Another point, I went down this road some time ago and found out that there's a huge diversity of daylight saving rules from place to place. Unless you're building something for a very localised area, you have practically no show of setting up rules that will apply to your entire target population.

To amplify what Rich said - The rules do change, and not so infrequently as you might hope. Its quite ugly. Hope that helps, Best Regards, Dave

PS: Worked on a product last year that stopped working correctly (in Europe) after the Indonesian tsunami... Time is a tricky business.

Not to mention that as soon as some legislature changes things your daylight savings time algorithm is shot to hell.

Not knowing your UI, I have to say that my favorite appliance that tracks DST is my thermostat: it has a "DST" button. Push it once, and the hour bumps up one. Push it again and it bumps down two (so if you started at

7:00 it goes to 8:00, then 6:00). One of those two is correct. If you pushed it by accident, push it _again_ and it goes back to the original time.

--
www.wescottdesign.com

There are nearly 200 independent countries in the world and some of them have a few time zones. In reality, there are at least 300-400 areas with different time zone rules. IIRC, in US there are some areas close to the Canada border with different time zones in the same US state.

This year Russia went into daylight saving time in the spring, but they did not return to normal time this autumn, thus all their time zones are different from last winter.

Running the RTC in local time is just asking for troubles. Run it in UTC and perform any time zone correction before displaying it to the end user.

If the RTC is accurate enough, there is also the question, should it run in UTC (with leap seconds) or simply linear GPS time (without leap seconds).

The classical TZ environment variable should do this.

IMHO, the simplest thing would be to run any high stability clock in GPS time and apply leap second, time zone and standard/daylight correction before presenting it to the end user.

The problem is the returning to standard time. Last weekend, most of the European countries returned from daylight time to standard time at

01:00 UTC, thus the same local time occurred between 01:00 .. 02:00 UTC. There is no "correct" answer to this problem, it has to be checked for each application separately.

My alarm clock uses NTP to set the time (it's on the internet anyway). However, it stores the timezone as a simple offset from GMT. You can set the offset manually twice a year, but I have a program running on a "real" computer with a full timezone database that changes the offset as needed, over the network.

cron... sunday morning... 3am... poke new offset to alarm clock...

My watch doesn't have a timezone database in it either, I just change it twice a year.

None that would survive the usual political provincialisms for any truly useful amount of time.

The closest one could come would be an equivalent to the full-fledged TZ environment variable supported in some environments, where you can basically write an entire little time manipulation script into the variable.

At least there are attempts to stay synchronized with that political mess at

Is this suitable for any small embedded system (clock etc.) is entirely an other question.

1. Make the user do it.
2. Sync to an external time server.

#2 isn't actually that simple, but it's still a lot simpler than maintaining a local timezone database.

It's a lot more than that. The standard timezone database has 1735 files, or 874 if you remove duplicates; although, some of those are only unique because they include historical data. Even so, 30 seems to be an extremely low estimate.

That is unwise. DOS used local time because it didn't have any concept of timezones; the RTC was used verbatim. Windows keeps the RTC in local time because backwards compatibility triumphs over sanity.

If you do go that route, make sure that you store a flag to indicate whether the time is in DST, otherwise you'll run into problems when the clocks go back.

The start and end dates change regularly. Any database needs to be continually updated to deal with legislatitive changes. If you sell to a dozen different markets, it's more likely than not that at least one of them will change their rules in any given year.

Doesn't every time server give you just UTC? You still need to do a correction based on the local timezone.

The product in question has a GPRS modem and can thus potentially access an HTTP server. Currently we don't use that; we just use SMTP to send emails. It also sends and receives SMS messages, and receiving those gives you time but it is the sender's time, which is potentially no good, plus there can be a long delay.

We have a facility for the user to set the RTC with a text message. The product will be remotely mounted, so that will have to be the way. We could also support the sending of an email to it, but there can be delays in that too, and it will use up its SIM card credit in checking some POP3 server for emails, periodically.

Yes; I can see that will be a huge mess. On a PC one can do it because M$ can deal with changes using their regular updates.

Most time protocols, such as NTP rely on that the uplink and downlink propagation delay is the same. This is not necessarily true with GPRS.

Since time zones are only at 15 minutes granularity and the typical propagation delay for any on-line system is definitely less than this, you should be able to determine the time zone differences from the message headers, even if the seconds are taken from your local RTC.

A simple solution is to send the device a SMS message containing the date/time of the upcoming daylight savings change. That way you only need to send 2 messages per year to each device.

I assume that each device has a local clock that's good enough for UTC timekeeping. If not, you asked the wrong question in the first place.

Nothing prevents you from running your own server which reports local time (I'm thinking about a simple "daytime"-style server, not NTP). OTOH, if the client can maintain synchronisition by itself, you can just run e.g. an HTTP server which the client would use to obtain (and maintain) the switch-over times for its local time zone. Checking for updates once a month should be sufficient to deal with even the most rushed legislative change.

[%X]

[%X]

Let the remote device keep time in UTC and send it a periodic (no less than bi-annual) message that lets it know when DST starts and ends. At the appropriate change-over time for it's locality it can then set a flag. Indication of user viewable time can then be displayed corrected for the DST and locality as appropriate.

--
********************************************************************
Paul E. Bennett...............
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

Peter skrev 2011-11-04 15:52:

My GSM phone (Symbian) will change time when I change Time Zone. (It will ask me for permission first) Don't know the internals, but maybe you should investigated what the GSM system can provide? They need to have a fairly exact clock in the system to make it work.

BR Ulf Samuelsson

Indeed they do. The network typically sends timezone info to mobile devices= , though this may depend on the operator.

There is a standard for the AT commands that GPRS modems use, although vend= ors may implement more or less as they see fit. Among these there may be co= mmands to get at the clock and timezone info in the GPRS modem. Eg. AT+CCLK= reads the clock. It's best to consult the manual for the device in questio= n to see what is available.

Indeed it does depend on the operator; when I go abroad my phone automatically adjusts the timezone, when I come back home it doesn't.

though this may depend on the operator.

may implement more or less as they see fit. Among these there may be commands to get at the clock and timezone info in the GPRS modem. Eg. AT+CCLK reads the clock. It's best to consult the manual for the device in question to see what is available.

On the Cinterion MC55i modem which we are using there is a real time clock but no apparent way of setting it - from AT commands or from the network.

We could indeed set up a server, as a service to our customers, which provides the current local time for every place in the world, making use of the ton of software in windoze or unix. But that is a bit of a hassle...

GSM time is not reliable. In some countries the typical option 'set clock from network' works, in some it doesn't.

According to the easily found online manual, the command to set the RTC is AT+CCLK= where is a string in the format "yy/mm/dd,hh:mm:ss".

sec 18.1, page 433.

Still need to know time to set the clock though.

George