martin.burnicki at meinberg.de
Fri Jul 4 09:30:15 UTC 2008
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.
> But you want a human friendly format for that.
>> If the OP's requirement is to check whether the uclibc functions would
>> switch to and back from DST at the right points of time then he could
> 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.
Agreed, the subject suggests you are right.
>> a little script or program that increments a UTC time stamp e.g. over a
>> year, let that time be converted to local time and see if the local time
> I did think of this, but really wanted to be sure the requirement was
> legitimate and the best solution first. Note this has to be done over
> the period for which you want the rule to be valid, e..g., for Pakistan,
> a rule generated for this year will not work for last year and it is
> anyone's guess as to whether it will work for next year. The OS may
> also give the wrong behaviour for years other than the current one.
Also agreed basically. However, if we're talking about an embedded system
the question is in which countries it is sold.
Also, even if the Olson libs are being used, the rules for Pakestan became
invalid and the libs had to be updated if Pakistan changed the rules in the
future. The time zone string had to be updated similarly if the rules
> I would say the best way of doing this automatically would be to have
> the code read the source version of the Olson database, as testing dates
> over a single year cannot necessarily distinguish between week 4 and
> week 5 type rules, etc. The rules may have been different for the
> previous year.
> The best way of doing it is probably to ask the user for the
> information, or even the complete string.
An interesting approach is also how Inova NTP POE wallclocks are working:
They also need a timezone string (I think in a proprietary format) which can
be composed using Inova's Daylight Saving Time Calculator:
The best thing is that you can put that string into a custom option (230 by
default) on your DHCP server, so if there are changes required in the
timezone string then you just have to update the DHCP server and the
displays will pick it up when they are powered on the next time.
More information about the questions