I am currently trying to convert a unix/epoch time (time_t type) to the local timezone's time using the localtime library function. The conversion from the time_t type to the tm structure type works well using this function, but the converted time is referenced to GMT.
Comments in time.h would make one believe that it should be possible to convert to the local timezone's time:
/* * converts the calendar time pointed to by timer into a broken-down time, * expressed a local time. * Returns: a pointer to that object. */
I have tried to find a way to configure the local timezone, but have been unsuccessful up to now.
Would anyone happen to know if it is feasible to configure the timezone that the library uses, and if so, how this would be done.
I am thanking you in advance for your help.
I don't see a simple way. Could you just apply the time zone offset to the integer?
An issue here is that time zones often have summer/winter time. And the dates - or if using daylight saving - are politically decided. So it isn't possible to ship a library with a mathematical function to correctly handle local time zones. The best possible is to ship a configuration file with time zone names, and with winter offset and then with a list of currently decided dates for switching to/from the optional daylight savings. And being based on politics, you then need a way to distribute a new list to all your shipped devices now and then as different countries decides to change their date rules or if they should or should not use DST.
So because of that, it is seldom meaningful for an embedded device to have general local-time support. It's better that you implement a configuration input interface where the user just specifies the time offset and dates for the next few summer/winter changes.
If you don't even have a full real-time clock that handles the calendar? Then you can't even manage changes to summer/winter time without having the user reconfigure the device twice/year just as you have to do with a normal w.a.t.c.h.
Another thing here is that in the general case, you have no standard physical clock that the compiler-supplied CRTL can use. Which makes it a bit awkward with all functions that relates to time - being compatible with a PC is only meaningful if the hardware is also reasonably compatible with a PC...
Anyone wondering about the w.a.t.c.h. thing in the previous post? One of Keil's failed attempts to protect from spam is to ban some semi-randomly selected words and produce a server error 500.100 to scare away the spammer. That it also catches valid posts seems to be irrelevant.
But at least less annoying than two weeks ago where threads I posted to ended up totally dead - Keil notified but they seem to prefer them left dead: http://www.keil.com/forum/59336/ http://www.keil.com/forum/59322/ http://www.keil.com/forum/59333/
The best possible is to ship a configuration file with time zone names, and with winter offset and then with a list of currently decided dates for switching to/from the optional daylight savings
It's not difficult to write routines to do universal to local time calculations; including support for daylight savings.
Then, you can have simple parameters to specify the rules for a given location.
I opted to make conversion routines to take a date/time and produce an integer, do the maths as required and then convert back again.
For me, the most useful feature of spending the time writing them is that I am in control and can include/exclude features as required. Very useful when the code is to be ported between a number of platforms with large differences in memory/processing resources.
The actual conversions are the easy bit.
The harder parts are knowing what timezone you are in, and knowing when (if at all) "daylight saving" needs to be applied - neither of which is "calculatable"
It is of course correct to say such information is not calculatable. But it's incorrect to say that knowing which timezone one is in is in any way harder. I know which one I am in, you probably know which you are in. And if you do not, then you should know how to ask a smart enough question to find out.
The processor won't be able to determine said information if it purely standalone, but the person setting up a system should be able to provide the necessary parameters (of which there are very few for any specific timezone).
So the only real hurdle is getting that information into the device and having it stored there.
For a device that is not standalone, that information can easily filter through from other equipment. Most servers have that information and they normally contain a frequently updated database of all timezone information.
While most servers have that information - or more specifically just about any machine running Windows, Linux, BSD, ... - they don't have it exported. They may run an ntpd server, but that ntpd server will not export the daylight savings database. So you must write a program and run on that server, to distribute the currently registered daylight savings dates.
And being politically decided, that also means that the dates can change, or DST can be introduced or removed, after you distributed the current content of that database. And small countries on the borders of a time zone border may decide to change their belonging, moving forward or backward the time with an hour - or possibly deciding on an half-hour offset.
Anyway - the code to work with time offsets in the embedded product is trivial. But it does require a full real-time clock. And it does require an interface where the user can configure the unit. And optionally a update server to retrieve the rule base from.
So the final complexities are quite significant compared to a device that just runs all the time on local time with zero knowledge of time zones, and instead expects the user to adjust the clock on a DST change or when the RTC have drifted too much.
Just a few comments:
So you must write a program and run on that server, to distribute the currently registered daylight savings dates.
Yes, but since a considerable amount of non-standalone equipment talks to a server anyway (else there'd be little point in it being non-standalone), the only extra piece is to add the ability to issue timezone detail.
Windows certainly does have that information. They update that information quite frequently through their software updates; so the process can be done automatically. I have little experience of Linux, but it would surprise me if that same information is not available to an application.
Anyway - the code to work with time offsets in the embedded product is trivial.
Applying an offset is, of course, simple. My experience in viewing code that others have written shows that the code for daylight saving calculations is prone to developers not considering all necessary aspects. Not difficult, but I wouldn't say it is trivial.
But it does require a full real-time clock.
Not necessarily. We have used devices that just maintain a simple 32 bit counter configured to increment once a second. That count can then goes through the same conversion routines I mentioned before.
And it does require an interface where the user can configure the unit.
Really, as indicated before, this would only be necessary on a standalone device. But since the standalone device would already need to have some setup of date/time, adding the few extra details for timezone should not be a great task. Unless a super-high accuracy clock is used, it would have to be adjusted occasionally anyway, so also saying that timezone details might be updates would surely not be a great problem.
A device that sits running on local time would still likely need the clock adjusted occasionally.
You can comfortably set the time using four 7-segment digits and two buttons.
But the world has a rather large number of time zones - way more than the 24 major time zones.
This Keil site for example is (or was) running on PST. But when it's easy to think of PST as Pacific Time Zone, it's also the name of Pitcairn Standard Time. Yesterday, both had the sime time offset. But Pitcairn Standard Time is used all around the year, while locales with Pacific Standard Time just some hours ago switched to PDT - Pacific Daylight Time.
When presenting a time zone selection to an end user, it's often needed to be able to list major cities in that time zone to make sure the user selects the time zone with the correct politically decided daylight savings rules, and not just accidentally selects a time zone with the same current time offset.
I'm not so sure a Windows machine does supply all the required information to be a proper time zone updater. The normal time zone API of most OS just allows you to select a time zone and then convert between UTC and local time. That isn't the same as being able to extract all the dates when DST changes. It's more common that people makes use of: http://timezonedb.com/ cs.ucla.edu/.../tz-link.htm or similar.
Next thing - lots of equipment aren't networked. So no access to database updates. But they can still keep their time using GPS or a radio-based time server.
In the end, there is a large number of things that can go wrong when using local time zones. And the customer will be angry when it goes wrong. While the customer will not be angry in a situation where the customer was informed that he/she has to adjust the clock on summer/winter time. And this all falls back on one thing - should really Keil's libraries introduce support for local time zone databases, when it can't be implemented in a general way without access to a network server or a significant user API where the user may enter all the required information? And the Keil library can't force the integration of such networking or user interfaces.
You can follow that approach, but it's certainly not the only one.
We have users who are comfortable with entering the details manually. When broken down, you can see that there are not very many.
I'm not so sure a Windows machine does supply all the required information to be a proper time zone updater.
We've managed it.
While the customer will not be angry in a situation where the customer was informed that he/she has to adjust the clock on summer/winter time.
You clearly have different customers to the some I've experienced. Twice a year, from regulars, we used to get calls from angry customers when the equipment didn't automatically change after they forgot what we'd clearly told them previously. Changing our strategy to always assuming universal time with local specific information removed lots of opportunities for complaints.
Next thing - lots of equipment aren't networked.
And even those can have details entered in other ways. For example, years ago we developed a standalone card reader which had the timezone details entered by inserting a configuration card which we'd set up on a PC. Incidentally, that PC was running software that automatically acquired the necessary timezone database.
With just a little imagination, a lot of perceived difficulties can be overcome.
With summer and winter time, there are closer to 250 time zones in use. I'd say that is quite a big number.
If I look in my local Windows registry, there are just over 100 "standard time" zones. Still quite a high number. But that Pitcairn Standard Time I mentioned earlier? Not in my Windows registry... A number of the registry entries have quite weak "Dynamic DST" information, outside of "now".
The net is absolutely stuffed with work-around code people have had to write to work with time zones on Windows, and to use SetDynamicTimeZoneInformation() or the .NET etc alternatives to stuff the Windows registry with enough information to actually work well when you need to support a larger range of years or a larger set of time zones. So while Windows do have support, it's a complicated route when it's so much easier to totally side-step and directly use a well-maintained tz database.
For a number of time zones, the Windows time zone information is able to supply the correct answer for "now" but not for dates in the past or following years. So the standard Windows time zone information can then not be distributed with a unit that will be offline for multiple years. There are exceptions, where Windows might have forward information until 2040 or even further. But there are too many situations where the reverse is true too.
No, our customers aren't specifically forgiving. But our devices are luckilly normally extremely networked. And totally server-configured. And most are mobile, making it hard to lock them down to a specific time zone. So all data is collected in UTC, and the customers specifies on the server side what TZ they want the information presented in. In some few situations, the units are at a fixed installation and needs local time zone support - in which case we supply the standard database package, with support to send out newer databases if needed.
When we do set out non-networked devices (which we try to avoid) or devices that must operate in closed networks without any "friendly" server accessible, we do go for the best information available today. And that information is not available in a Windows machine unless someone have fed the machine from a non-MS source.
It certainly is. That is why we give the users the option to enter the detail manually (i.e., the raw detail). And being raw, there is a whole lot less. It could be argued that we use an apolitical method of configuration.
The net is absolutely stuffed with work-around code people have had to write to work with time zones on Windows...
That may well be the case. But we don't. We access that timezone database for a given location. It's not at all complicated.
So all data is collected in UTC, and the customers specifies on the server side what TZ they want the information presented in.
Exactly as we do. But, for us, some equipment has to display the local time and/or react for events relative to the local timezone. Having that information is therefore critical.
in which case we supply the standard database package
We prefer to send the raw detail. Certainly for us, we would send the device information about its location anyway, so it might as well just be sent what it really needs.
You can use the time on the U.S.N.O. Master Clock to determine how many hours different your local time is from Universal Time. Once noted, use this number to convert all eclipse prediction times from UT to your own local time.
For example, if you are in the Eastern Standard Time zone, you will see that your local time is 5 hours earlier than UT. In order to convert any eclipse predictions from UT to local time (i.e. - EST), you must subtract 5 hours from UT:
Local Time = UT - 5 hours