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