martin.burnicki at meinberg.de
Mon Jul 7 12:43:47 UTC 2008
> On Jul 4, 2:30 pm, Martin Burnicki <martin.burni... at meinberg.de>
>> David Woolley wrote:
>> > Martin Burnicki wrote:
>> >> The best reason I can think of is to check in advance whether the
>> >> local time will swich to and back from DST at the correct points in
>> >> time, so you won't get a bad surprise when it doesn't happen.
> Well i just want to support a option in my embedded device for:
> "being able to set timezone for this device as timezone which is used
> on other machines(windows or linux box) that user have and i do not
> want user to specify the complete string. He/she will have access to
> which device can use readily.
Understood. However, this can be much trickier than it looks at the first
If your conversion should work universally then you have to write a routine
which reads in the timezone settings of the Windows or Linux box, and
convert it to the string format expected by uclibc. You have to check for
all range limits and exceptions of the source format and have to cover all
of this in your uclibc format.
Depending on the operating system and C library there may be different
formats to specify different time zones, even with different possibilities.
You must even check if a set of configuration parameters describes a rule
which can be applied for several years, or exact dates of beginning and end
of DST, which are only valid for one year. Setting s which are valid for
one year only can be useful e.g. in Pakistan (David ;-)) or in Israel,
where the end of DST does not just depend on a simple rule (last Sunday of
October ...) but on a certain day related to a Jewish holifday, see:
E.g. under Windows the timezone settings are kept in the registry and can be
retrieved using the structure TIME_ZONE_INFORMATION.
Possible settings allow either for a rule, or for exact dates:
- if months=0 then no DST is observed
- absolute dates: year, month, day-of-month, and time must be specified
- rule dates: year must be 0, day-of-week according to requirements,
day-of-month 1-5 (1st to 4th, 5 == last)
Here are some rules which specify Central European Time, i.e Europe/Berlin:
M3.5.0 = daylight saving starts the 0th day (Sunday) in the last week (5) of
month March (3)
OS/2 Warp 4:
Though the OS/2 format looks similar to the glibc/uclibc format, there are
some differences which needed to be handled.
A quick internet search didn't return any results how you can specify an
exact date using this formats, I'd think you have to create rules which
yield the desired dates for the given year.
For example, in Meinberg GPS receivers you can also either specify the exact
date (year, month, day-of-month) or a rule (wildcard year, month
day-of-month, and day-of-week). In the latter case the changeover occurse
at the first day-of-week on or after the configured date.
>> > My concern was that the requirement wws too artificial and it might be
>> > homework. However, it doesn't read to me as though this is about
>> > checking the behaviour, but about generating the rules on the
>> > assumption that the behaviour will be correct.
> Believe me this is not homework and i have done my homework , IMO.
Please note it wasn't me who has made the remark concerning your homework.
> I also found the link http://www.merlyn.demon.co.uk/js-datec.htm#GUTZ
> but was not sure if its accurate. I tested it for few timezone setting
> for which it seemed to work. Any inputs on this ?? Does it handle all
> the cases ?
It's not too hard to create a rule string from a set of given constraints.
IMO it's much harder to pick up one rule string and convert it into another
one, depending on the source and target formats, and all the limitations of
Making sure this works correctly requires a look at the code, not only to
check a few conversions which may occasionally work correctly.
More information about the questions