will.u.tellmemore at gmail.com
Mon Jul 7 06:57:29 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.
> > 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
> >> write
> > 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.
> 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 InovaNTPPOE wallclocks are working:http://www.buyinova.com
> They also need a timezone string (I think in a proprietary format) which can
> be composed using Inova's Daylight Saving Time Calculator:http://www.buyinova.com/index.php?option=com_wrapper&Itemid=49
> 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.
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 ?
> Martin Burnicki
> Meinberg Funkuhren
> Bad Pyrmont
More information about the questions