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 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. > 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. 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. > handles DST correctly. _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
