pytz has so many timezones!

[J. Cliff Dyer]

On 10/8/07, *J. Clifford Dyer* <jcd at sdf.lonestar.org
<mailto:jcd at sdf.lonestar.org>> wrote:

    On Mon, Oct 08, 2007 at 01:13:24PM -0700, mensanator at aol.com
    <mailto:mensanator at aol.com> wrote regarding Re: pytz has so many
    timezones!:
    >
    > On Oct 8, 1:03 pm, Carsten Haese < cars... at uniqsys.com
    <mailto:cars... at uniqsys.com>> wrote:
    > > On Mon, 2007-10-08 at 10:41 -0700, mensana... at aol.com
    <mailto:mensana... at aol.com> wrote:
    > > > For example, Windows has seperate listings for
    > >
    > > > Central America
    > > > Central Time (US & Canada)
    > > > Guadalahara, Mexico City, Monterry - New
    > > > Guadalahara, Mexico City, Monterry - Old
    > > > Saskatchewan
    > >
    > > > but they are all GMT-6
    > >
    > > But they could have different rules for Daylight Saving Time.
    >
    > Which only matters if you're setting your clock.
    >

    Maybe this is where I'm not understanding you:  Do you have another
    use for setting a timezone?  The only thing a time zone does, as far
    as I can tell, is set clocks relative to a shared conception of time.


    --
    http://mail.python.org/mailman/listinfo/python-list





> How about a calendar entry: I've got six people in places all over the
> world to get on the phone together.  If the app doesn't know their
> notion of a time zone, that will never happen.
>
> How about financial transactions: time-stamping transactions that move
> around the world seems pretty useful to me.  How do I know when said
> transaction started if I can't convert the user's time into the
> server's time?
>
> Timezone is just another localization setting.  It is no different
> than language or keyboard layout.  It is a piece of data that
> describes the "world" the user lives in.  Unfortunately, DST makes
> them very complex because DST is determined by the country and can
> change from year to year.  I think the US' DST change this year had
> more of a real-world impact than Y2K (of course, people actually
> planned for Y2K, but that is a different story :).
>
> tj
>


OK.  Those all make sense, but I think they contradict mensanator's
statement that DST and half-hour offsets "only matter[] if you're
setting your clock."  None of those are meaningful with 25 generic time
zones, which was what I was trying to understand.  Under what normal
circumstances (outside of the US military creating an approximation for
their own internal usage) could 25 tzs be a useful abstraction?

Cheers,
Cliff