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.
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