david at ex.djwhome.demon.co.uk.invalid
Fri Jul 4 07:59:57 UTC 2008
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
The best way of doing it is probably to ask the user for the
information, or even the complete string.
> handles DST correctly.
More information about the questions