On Mon, 28 Oct 2002, Brian J. Murrell wrote:
>>yes, but download the package and see how many corner cases there are.
>>that's my point.
>
>No argument Jerry. Really. I know there are a lot of corner cases.
>That is why I think leveraging the existing data on this subject is
>a good approach. Somebody else has already gone to the effort of
>all this localization crap (see the timezone package on most linux
>distros), so let's use it.
I think there are two things here. One is the algorithm that, given
the possible timezones and when they change over, can guess the
timezone that goes with a date. We have this specialized to GMT/BST
in UK_TZ.pm and Cal::Date may provide it more generally.
Next, there is the question of how to get this timezone
information. We can prompt for it at configuration or we can extract
it from a big timezone database.
The nice thing is that these tasks are fairly orthogonal. You can
write a first implementation that prompts for timezone and changeover
dates, and meanwhile you or someone else can be working out how to get
these automatically by selecting from a list of timezones. The corner
cases in guessing the tz for a date do not affect selecting your tz
info at configuration, and whatever method you use to prompt the user
or guess the tzs that apply to the listings, it doesn't affect the way
in which you handle dates from the site.
--
Ed Avis <ed@xxxxxxxxxxx>
|
