Rohit, Rohit wrote: > 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.
Understood. However, this can be much trickier than it looks at the first glance. 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: http://www.gov.il/FirstGov/NewsEng/NewsEng_DaylightSavingTime.htm 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: glibc/uclibc: "CET-1CEST-2,M3.5.0/02:00:00,M10.5.0/03:00:00" M3.5.0 = daylight saving starts the 0th day (Sunday) in the last week (5) of month March (3) http://www.gnu.org/software/libtool/manual/libc/TZ-Variable.html http://www.uclibc.org/downloads/Glibc_vs_uClibc_Differences.txt OS/2 Warp 4: "CET-1CST,3,-1,0,7200,10,-1,0,10800,3600" http://www.opweb.de/en/csdp/SET_TZ.htm 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 each format. Making sure this works correctly requires a look at the code, not only to check a few conversions which may occasionally work correctly. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
