Hi all,
I would like to use the time library to manage multiple times with different timezones in my embedded system.
I would like reproduce the IAR method: (www.iar.com/.../)
But with Keil MDK-ARM, I don't find the solution to manage the different timezones or switch the current rule of the timezone. I don't find any API. I don't if it's necessary to write weak functions...
Can you help me?
In advance, thank you.
How will your system know what timezone it is in, and what the DST rules are for its location?
With a string same like : ":GMT+0:GMT+0:+0000" Where :GMT+0:GMT+0 is for Time zone data and :+0000 for DST.
We just use simple comms to specify locale information on our system at commission and maintenance time. So an LCD can show a local time. It's hardly rocket science.
Ok ok thank you for your help.
But where does that come from?
If you are connected to a system which has that information, why does the embedded system need to do it itself ... ?
So do you just do "maintenance" at the start and end of DST?
"It's hardly rocket science"
Trouble is, it's not science at all - the relation between geographic location, timezone, and DST rules is purely arbitrary.
the relation between geographic location, timezone, and DST rules is purely arbitrary.
And not only that: all of those elements can change at literally any time. Systems get moved to different geographical locations without noticing. Geographic locations decide to join different timezones. DST transition dates can change on little to no notice, and sometimes DST is just abolished. And that's before you consider what your system should do in case it just lost track of time itself (power-cut, anyone)?
E.g. there's a good chance the European Union at large will cease DST'ing in the foreseeable future, and who knows, maybe some of the more absurdly bollocksed country-to-TZ assignments will be rectified in the process, too. OTOH, there'll be politicians involved, so the "is like a box of chocolates" rule does apply...
It's a losing proposition to handle all that nonsense algorithmically on a limited embedded system.
No. I can't understand why you would even suggest such a problematic scheme.
The units are loaded with locale information so the local time is generated from UTC. Daylight saving changes occurs by way of simple pre-determined rules and without user interaction.
The locale information is uploaded as and when required. Although it is a 'man made' system, any changes are usually rare and notification is received in good time to allow maintenance to be scheduled well in advance.
To focus the discussion on my request, please, read my first post. Also, I indicate that my embedded system can receive the new rules for its location with the following string format: ":GMT+0:GMT+0:+0000".
So why does it need to manage time zones & DST at all?
Simply send it the current offset, and re-send whenever it changes.
Simples!
Finally, I agree with you, thank you !
You're welcome!
You'd probably want to have some way to specify when the change should be applied ...
That is such a crude method, but since the OP's happy I'll not rock the boat.
You can suggest your complete solution if you want.
I would prefer to say, "simple".
I basically did before.
The advantage of doing this is that any daylight saving changeover occurs automatically AT THE PRECISE TIME OF THE CHANGEOVER without having to rely on someone coming along sometime prior or sometime after the changeover. Having to rely on someone to manually issue a different offset at or around the changeover time is just horribly crude!
I've not looked into the detail of library functions for this automatic changeover. We chose to implement our own routines back in 2001 and they continue to operate nicely with no foreseen issues expected. These changeover determination operations and application of offset are not complex.