Is there an easy way to implement daylight saving changes?

It makes a HUGE difference exactly what the application is. Changing the time automatically can indeed be "nice" but it can also be a pain, and even dangerous.

For real-time embedded applications that control things, I vote with someone else who said often times the best and simplest way to do it is have the user do it manually. True, a step is required to do that, but the step provides acknowledgement and awareness of the time change and any consequences that might result from it.

If an automatic irrigation sprayer is supposed to run at 1:30 AM, in the fall when the time sets back, it will run twice since 1:30 occurrs twice that morning, one hour apart. Then in the spring when the time goes forward, the sprayer will not run at all that morning since there will not a 1:30 AM.

A couple of reasons the 1:00 AM to 2:00 AM period to change the time was chosen are: a) not many things are scheculed for that time of day; and b) no date and day of week change is required. But still it can mess up things like logging. So in the fall, you could make a phone call at 1:45 AM and make one "later" at 1:15 AM. I don't know what would get logged if you made a call like that in the spring.

There shouldn't be any bugs in requiring an operator to change it, maybe an inconvenience. But as I started out saying, it makes a HUGE difference exactly what the application is.

Lou

Reply to
Mr. C
Loading thread data ...

Yes. Make it REALLY EASY for the user to increment/decrement the current hour.

Really.

There are too many variabilities in DST -- geography, legislation, etc. E.g., the entire country (USA) just "moved, in time" relative to *us*, recently. *Our* clocks didn't change but we now have to recall that everyone *else's* has!

I have a small "atomic" clock by my bedside. It has a graphic of the USA on the screen. A button lets the user cycle the highighted portion of the country through the various timezones to effectively offset the "broadcast ToD". I can do this without messing with the time setting.

(unfortunately, it is disconcerting to see the west coast highlighted while not actually *living* there!)

Reply to
D Yuniskis

That would be quite a good solution.

However, in this case the device is located remotely. Moreover, it has no user interface (no LCD, etc) on the outside.

We have a means of setting the RTC using an SMS message containing the desired date/time, so we will run with that and see how it goes.

The next option, a lot more complicated to implement as well as using up the SIM card credit more quickly, would be to get the device to periodically access a server at our office, using probably HTTP (which is supported with the TCP/IP stack in the MC55i modem), and have software running on that server which delivers the current local time for every country in the world that appears on the standard Windoze timezone pulldown menu (about 30 zones IIRC).

The reason for needing *local* time in our device is that the messages it sends can be routed to different personnel according to time of day, to support people working different shifts. If your shift ended say 0800 and you are about to jump into bed then you don't want to receive a message at 0855 saying you need to drive 100 miles somewhere :) That message needs to go to the person who is on call from 0800.

It would be nice if one could pick up reliable local time from the GSM system, without incurring any call charges :)

Reply to
Peter

Then why on earth are you even _thinking_ about wall-clock time, much less daylight saving?

Daylight saving matters only to people. Machine-to-machine communication should never use anything other than UTC.

So handle that stuff on the server where you have all the necessary information in one place.

Reply to
Hans-Bernhard Bröker

I'd have to agree. Store everything in UTC and convert it to local time as it's diplayed. Only the program that displays the data to the user needs to know about timezones.

--
Grant Edwards               grant.b.edwards        Yow! I am a traffic light,
                                  at               and Alan Ginzberg kidnapped
 Click to see the full signature
Reply to
Grant Edwards

Agreed. Unless the device tends to "move around" FREQUENTLY, track it's location from your "central office" () and dispatch "set DISPLAYED time offset" commands to the device as you see fit (based on your knowledge of the device's location).

Note that you can probably *query* that information from the device in one of your routine update/query cycles (ideally, if the device has GPS available to it *or* simply ask the user to tell the device "where it is" as part of the setup routine -- don't even let the user set the time!! Just tell you where it is {city,country} and you sort it out from there.)

Reply to
D Yuniskis

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.