On Jul 4, 2:30 pm, Martin Burnicki <[EMAIL PROTECTED]> wrote: > 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 javascript which will get/generate timezone string in this format 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 > changed. > > > 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 ? -- Rohit > Martin > -- > Martin Burnicki > > Meinberg Funkuhren > Bad Pyrmont > Germany _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
