pytz has so many timezones!

mensanator at aol.com mensanator at aol.com
Mon Oct 8 20:41:47 EDT 2007


On Oct 8, 5:48 pm, "J. Cliff Dyer" <j... at sdf.lonestar.org> wrote:
> On 10/8/07, *J. Clifford Dyer* <j... at sdf.lonestar.org
>
> <mailto:j... at sdf.lonestar.org>> wrote:
>
>     On Mon, Oct 08, 2007 at 01:13:24PM -0700, mensana... at aol.com
>     <mailto:mensana... 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?

It's how the world goes around.

Some people can't see the forest for the trees.

Is it obvious from all this timezone crap that

 - a day lasts 48 hours?

 - it can never be the same day everywhere in the world
   simultaneously?

Isn't that just as important for worldwide transactions
as Daylight Savings Time (or lack thereof)?

Perhaps, once the basics
<http://members.aol.com/rotanasnem/truth/eykw_t40.htm>
are understood, the details won't be so confusing.

>
> Cheers,
> Cliff




More information about the Python-list mailing list