On Thu, Oct 4, 2012 at 7:01 PM, Zachary Ware
wrote:
> It occurred to me this morning that Python already ships a set of
> timezone data with the Windows installer: Tcl/Tk's. Is there any way
> we could use that as the default on Windows?
We could, but it wouldn't solve any of the problems that n
On Thu, Oct 4, 2012 at 12:01 PM, Zachary Ware
wrote:
> It occurred to me this morning that Python already ships a set of
> timezone data with the Windows installer: Tcl/Tk's. Is there any way
> we could use that as the default on Windows?
I would say no. You could choose not to include Tcl/Tk in
It occurred to me this morning that Python already ships a set of
timezone data with the Windows installer: Tcl/Tk's. Is there any way
we could use that as the default on Windows?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/m
On Mon, 01 Oct 2012 21:59:03 +0200, Lennart Regebro wrote:
> On Mon, Oct 1, 2012 at 9:02 PM, R. David Murray wrote:
> > On Tue, 02 Oct 2012 00:18:10 +0530, Nick Coghlan wrote:
> >> Reminder to everyone: the current state of the art for getting up to
> >> date tz info for Python is "pip install p
Matthias Klose wrote:
On 30.09.2012 20:18, Gregory P. Smith wrote:
priority:
1) api call supplying tz data to the process.
2) pytzdata module if it exists
3) tz data from the underlying operating system
4) error.
I disagree on this order, at least for Linux systems. the tzdata database
On Mon, Oct 1, 2012 at 9:02 PM, R. David Murray wrote:
> On Tue, 02 Oct 2012 00:18:10 +0530, Nick Coghlan wrote:
>> Reminder to everyone: the current state of the art for getting up to
>> date tz info for Python is "pip install pytz".
>>
>> If any proposal is more complicated than that, there's a
On Mon, Oct 1, 2012 at 12:02 PM, Barry Warsaw wrote:
> On Oct 02, 2012, at 12:18 AM, Nick Coghlan wrote:
>
>>Reminder to everyone: the current state of the art for getting up to
>>date tz info for Python is "pip install pytz".
>>
>>If any proposal is more complicated than that, there's absolutely
Gah, ignore half of that last post. I think Lennart is talking
about incorporating the missing pytz *functionality* into
the stdlib.
--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/01/2012 02:48 PM, Nick Coghlan wrote:
> Reminder to everyone: the current state of the art for getting up to
> date tz info for Python is "pip install pytz".
>
> If any proposal is more complicated than that, there's absolutely no
> point in
On Oct 02, 2012, at 12:18 AM, Nick Coghlan wrote:
>Reminder to everyone: the current state of the art for getting up to
>date tz info for Python is "pip install pytz".
>
>If any proposal is more complicated than that, there's absolutely no
>point in changing anything. The version I liked best so f
On Mon, Oct 1, 2012 at 8:48 PM, Nick Coghlan wrote:
> If any proposal is more complicated than that, there's absolutely no
> point in changing anything. The version I liked best so far is for
> Python to just install a copy of pytz automatically (shipping it in
> the installer rather than download
On Tue, 02 Oct 2012 00:18:10 +0530, Nick Coghlan wrote:
> Reminder to everyone: the current state of the art for getting up to
> date tz info for Python is "pip install pytz".
>
> If any proposal is more complicated than that, there's absolutely no
> point in changing anything. The version I like
Reminder to everyone: the current state of the art for getting up to
date tz info for Python is "pip install pytz".
If any proposal is more complicated than that, there's absolutely no
point in changing anything. The version I liked best so far is for
Python to just install a copy of pytz automati
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/01/2012 10:12 AM, Antoine Pitrou wrote:
> On Mon, 1 Oct 2012 16:06:18 +0200 Lennart Regebro
> wrote:
>> Actually, that's not a bad idea. My original idea was to warn if it
>> *was* outdated, but since there is no way to check that, I scratched
>
On 10/1/2012 12:39 PM, Lennart Regebro wrote:
On Mon, Oct 1, 2012 at 6:21 PM, Larry Hastings mailto:la...@hastings.org>> wrote:
On 10/01/2012 04:29 PM, Barry Warsaw wrote:
Using the script I mentioned in an different response, if someone installed
the database to some location (TBD)
On Mon, Oct 1, 2012 at 6:21 PM, Larry Hastings wrote:
> On 10/01/2012 04:29 PM, Barry Warsaw wrote:
>
> Using the script I mentioned in an different response, if someone installed
> the database to some location (TBD), then there would probably be a config
> file sitting next to it. A simple .i
On 10/01/2012 04:29 PM, Barry Warsaw wrote:
Using the script I mentioned in an different response, if someone installed
the database to some location (TBD), then there would probably be a config
file sitting next to it. A simple .ini file with an 'enable' flag would be
needed to turn on the over
On Mon, Oct 1, 2012 at 5:32 PM, Terry Reedy wrote:
> On 10/1/2012 10:06 AM, Lennart Regebro wrote:
>
> Actually, that's not a bad idea. My original idea was to warn if it
>> *was* outdated, but since there is no way to check that, I scratched
>> that idea.
>>
>
> Is there really no way to get a
On Mon, Oct 1, 2012 at 5:38 PM, Barry Warsaw wrote:
> On Oct 01, 2012, at 05:29 PM, Lennart Regebro wrote:
>
> >We seem to be on the same page here.
>
> Well, that was easy! Maybe I should be your PEP Czar :)
>
That sounds great!
What's a PEP Czar?
//My First PEP
_
On 2012-10-01, at 17:32 , Terry Reedy wrote:
> On 10/1/2012 10:06 AM, Lennart Regebro wrote:
>
>> Actually, that's not a bad idea. My original idea was to warn if it
>> *was* outdated, but since there is no way to check that, I scratched
>> that idea.
>
> Is there really no way to get a 'last up
On Mon, 1 Oct 2012 11:25:08 -0400
Barry Warsaw wrote:
>
> If you have an OS that keeps the system tz data up-to-date, I can't think of
> any reason why you wouldn't want to use it.
>
> If you don't have the data, why not include information in the documentation
> for how to download and install
On Oct 01, 2012, at 05:29 PM, Lennart Regebro wrote:
>We seem to be on the same page here.
Well, that was easy! Maybe I should be your PEP Czar :)
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http
On Mon, Oct 1, 2012 at 5:29 PM, Barry Warsaw wrote:
> On Oct 01, 2012, at 05:15 PM, Lennart Regebro wrote:
>
> >On Mon, Oct 1, 2012 at 5:11 PM, Barry Warsaw wrote:
> >
> >> I completely agree that just installing the Cheeseshop tz package should
> >> *not* be enough to prefer it over the system
On 10/1/2012 10:06 AM, Lennart Regebro wrote:
Actually, that's not a bad idea. My original idea was to warn if it
*was* outdated, but since there is no way to check that, I scratched
that idea.
Is there really no way to get a 'last updated' time from the site where
the database is kept? If no
On Oct 01, 2012, at 05:15 PM, Lennart Regebro wrote:
>On Mon, Oct 1, 2012 at 5:11 PM, Barry Warsaw wrote:
>
>> I completely agree that just installing the Cheeseshop tz package should
>> *not* be enough to prefer it over the system tz data.
>
>Do you have another potential mechanism in mind?
Yes
On Mon, Oct 1, 2012 at 5:25 PM, Barry Warsaw wrote:
> On Sep 30, 2012, at 02:47 PM, Lennart Regebro wrote:
>
> >The problem with including pytz in the stdlib is that it contains the
> >tz/zoneinfo/Olson database, and it updates much more often than Python
> >does.
>
> Why include the database in
On Mon, 1 Oct 2012 10:16:16 -0500
Zachary Ware wrote:
> >
> > But I don't think a warning is warranted, anymore than for other known
> > issues (there are many of them at http://bugs.python.org/ :-)).
> >
>
> Just curious (and a bit off topic), what exactly does warrant a warning in
> Python? I'v
On Sep 30, 2012, at 02:47 PM, Lennart Regebro wrote:
>The problem with including pytz in the stdlib is that it contains the
>tz/zoneinfo/Olson database, and it updates much more often than Python
>does.
Why include the database in Python at all?
If you have an OS that keeps the system tz data up
On Mon, 1 Oct 2012 11:11:46 -0400
Barry Warsaw wrote:
>
> I agree. I don't think the Python RM should have to worry about tz updates,
> given how frequent or unpredictable they can be.
I don't understand what makes them specifically "unpredictable".
We statically link OpenSSL and other librarie
On Oct 1, 2012 10:06 AM, "Antoine Pitrou" wrote:
>
> On Mon, 1 Oct 2012 09:52:09 -0500
> Zachary Ware wrote:
> >
> > My thought was that it's better to have *something* always available,
> > that has a decent chance of being "good enough" in a lot of cases (and
> > if it's good enough for you, ju
On Mon, Oct 1, 2012 at 5:11 PM, Barry Warsaw wrote:
> I completely agree that just installing the Cheeseshop tz package should
> *not*
> be enough to prefer it over the system tz data.
Do you have another potential mechanism in mind?
//Lennart
___
Py
On Oct 01, 2012, at 03:34 PM, Lennart Regebro wrote:
>On Mon, Oct 1, 2012 at 3:22 PM, Nick Coghlan wrote:
>
>> 1. Consider TZ database updates to be bug fixes, and thus include them
>> in maintenance releases. This will keep the provided version
>> reasonably fresh for Python versions that are st
On Mon, 1 Oct 2012 09:52:09 -0500
Zachary Ware wrote:
>
> My thought was that it's better to have *something* always available,
> that has a decent chance of being "good enough" in a lot of cases (and
> if it's good enough for you, just silence the warning), than to
> noisily fail because we can'
On Mon, Oct 1, 2012 at 9:12 AM, Antoine Pitrou wrote:
> On Mon, 1 Oct 2012 16:06:18 +0200
> Lennart Regebro wrote:
>> Actually, that's not a bad idea. My original idea was to warn if it *was*
>> outdated, but since there is no way to check that, I scratched that idea.
>> But as I have pointed out
On Mon, 1 Oct 2012 16:06:18 +0200
Lennart Regebro wrote:
> Actually, that's not a bad idea. My original idea was to warn if it *was*
> outdated, but since there is no way to check that, I scratched that idea.
> But as I have pointed out several times, a database that is shipped with
> Python is al
On 10/01/2012 12:07 AM, Chris Angelico wrote:
There's no guarantee that an individual sysadmin will have OS updates
up-to-date.
Is there a way of asking the database its revision / date? If so we
could simply use the freshest data we can lay our hands on.
//arry/
__
On Mon, Oct 1, 2012 at 3:57 PM, Zachary Ware
wrote:
> Re: to bundle or not to bundle
>
> What about having an included database that issues a (silence-able)
> warning any time it is used/imported/etc.? Have it say something to the
> effect of "Warning, the Olson database included with Python is li
Re: to bundle or not to bundle
What about having an included database that issues a (silence-able) warning
any time it is used/imported/etc.? Have it say something to the effect of
"Warning, the Olson database included with Python is likely to be outdated,
please see for information" where (whic
On Mon, Oct 1, 2012 at 3:22 PM, Nick Coghlan wrote:
> If a timezone database is bundled into the standard library, there are
> 3 clear mechanisms for encouraging the use of fresh TZ data:
>
> 1. Consider TZ database updates to be bug fixes, and thus include them
> in maintenance releases. This wi
On Mon, Oct 1, 2012 at 3:22 PM, Nick Coghlan wrote:
> Since explicit is better than implicit, I *wouldn't* want to see
> magical side affects where merely installing the database from PyPI,
> or switching from Windows to Linux caused different behaviour.
I think that would be a pain. What you're
On Mon, Oct 1, 2012 at 1:53 PM, Antoine Pitrou wrote:
> Python 2.3 has been EOL'ed for years. It definitely is not up-to-date,
> for any reasonable definition of the term. For example, it will have
> many unplugged security holes. So will that user's version of OpenSSL
> and other libraries. If t
On Mon, Oct 1, 2012 at 5:23 PM, Antoine Pitrou wrote:
> Python 2.3 has been EOL'ed for years. It definitely is not up-to-date,
> for any reasonable definition of the term. For example, it will have
> many unplugged security holes. So will that user's version of OpenSSL
> and other libraries. If th
On Mon, 1 Oct 2012 12:11:41 +0200
Lennart Regebro wrote:
> On Mon, Oct 1, 2012 at 11:16 AM, Dirkjan Ochtman wrote:
>
> > On Mon, Oct 1, 2012 at 10:47 AM, Lennart Regebro
> > wrote:
> > > A year is no age for a Python installation. A customer of mine has one
> > > website developed in 2003, stil
On Mon, Oct 1, 2012 at 11:16 AM, Dirkjan Ochtman wrote:
> On Mon, Oct 1, 2012 at 10:47 AM, Lennart Regebro
> wrote:
> > A year is no age for a Python installation. A customer of mine has one
> > website developed in 2003, still running on the same server. It runs
> Python
> > 2.3, I don't rememb
On Mon, Oct 1, 2012 at 10:47 AM, Lennart Regebro wrote:
> A year is no age for a Python installation. A customer of mine has one
> website developed in 2003, still running on the same server. It runs Python
> 2.3, I don't remember which version, but I'd be surprised if it is 2.3.7
> from 2008.
Ri
On Mon, Oct 1, 2012 at 10:28 AM, Dirkjan Ochtman wrote:
> I think that would be a little too pure to be practical. There are
> many practical usages of tz data that would work fine with a year-old
> timezone database.
>
A year is no age for a Python installation. A customer of mine has one
websi
On Mon, Oct 1, 2012 at 9:02 AM, Lennart Regebro wrote:
> I don't want to default to a database that is guaranteed to be out of date.
> I don't see the purpose. This is also why I'm skeptical at including the
> data on Windows.
I think that would be a little too pure to be practical. There are
man
On Mon, Oct 1, 2012 at 1:24 AM, Christian Heimes wrote:
> I like your basic approach but I'm suggesting a slightly different
> approach. Before I explain my proposal I like to get a naming convention
> straight.
>
> integrated tz database
> --
>
> A copy of the Olson database t
Am 30.09.2012 20:18, schrieb Gregory P. Smith:
> We never hear anyone complain because the corrections are not for
> English or other "western" languages that the majority of us speak. ;)
>
> Regardless, I think including a version of the database on windows
> releases makes sense. Update it on
On 01.10.2012 01:07, Chris Angelico wrote:
> On Mon, Oct 1, 2012 at 8:17 AM, Matthias Klose wrote:
>> On 30.09.2012 20:18, Gregory P. Smith wrote:
>>> priority:
>>> 1) api call supplying tz data to the process.
>>> 2) pytzdata module if it exists
>>> 3) tz data from the underlying operating
On Mon, Oct 1, 2012 at 8:17 AM, Matthias Klose wrote:
> On 30.09.2012 20:18, Gregory P. Smith wrote:
>> priority:
>> 1) api call supplying tz data to the process.
>> 2) pytzdata module if it exists
>> 3) tz data from the underlying operating system
>> 4) error.
>
> I disagree on this order
On 01.10.2012 00:51, Lennart Regebro wrote:
> On Mon, Oct 1, 2012 at 12:17 AM, Matthias Klose wrote:
>
>>> priority:
>>> 1) api call supplying tz data to the process.
>>> 2) pytzdata module if it exists
>>> 3) tz data from the underlying operating system
>>> 4) error.
>>
>> I disagree on
On 01.10.2012 00:50, Gregory P. Smith wrote:
> On Sun, Sep 30, 2012 at 3:17 PM, Matthias Klose wrote:
>
>> On 30.09.2012 20:18, Gregory P. Smith wrote:
>>> On Sun, Sep 30, 2012 at 8:33 AM, Benjamin Peterson >> wrote:
>>>
2012/9/30 Xavier Morel :
> But at worst, an outdated unicode databa
On Mon, Oct 1, 2012 at 12:17 AM, Matthias Klose wrote:
> > priority:
> > 1) api call supplying tz data to the process.
> > 2) pytzdata module if it exists
> > 3) tz data from the underlying operating system
> > 4) error.
>
> I disagree on this order, at least for Linux systems. the tzdata
On Sun, Sep 30, 2012 at 3:17 PM, Matthias Klose wrote:
> On 30.09.2012 20:18, Gregory P. Smith wrote:
> > On Sun, Sep 30, 2012 at 8:33 AM, Benjamin Peterson >wrote:
> >
> >> 2012/9/30 Xavier Morel :
> >>> But at worst, an outdated unicode database will be missing data right?
> >>>
> >>> Doesn't
On 30.09.2012 20:18, Gregory P. Smith wrote:
> On Sun, Sep 30, 2012 at 8:33 AM, Benjamin Peterson wrote:
>
>> 2012/9/30 Xavier Morel :
>>> But at worst, an outdated unicode database will be missing data right?
>>>
>>> Doesn't an outdated timezone db have the risk of returning *incorrect*
>> data?
On Mon, 01 Oct 2012 00:28:41 +0300
Serhiy Storchaka wrote:
> On 30.09.12 22:51, Antoine Pitrou wrote:
> > Well, no, this isn't similar. Choosing one's timezone policies is a
> > contemporary political decision, while choosing a language and its
> > alphabet is not really a decision people ever mak
On Sun, Sep 30, 2012 at 11:28 PM, Serhiy Storchaka wrote:
> Why not use the system data which are updated by the OS? I know that
> Windows also changes the clock for local DST.
>
The Windows timezone information does not include any historical
information, as it's designed primarily to keep your
On 30.09.12 22:51, Antoine Pitrou wrote:
Well, no, this isn't similar. Choosing one's timezone policies is a
contemporary political decision, while choosing a language and its
alphabet is not really a decision people ever make (it's just an aspect
of a society's long-term evolution) - except Atat
On Sep 30, 2012 10:34 PM, "Guido van Rossum" wrote:
>>
>> When people use pytz they have to reinstall pytz too if thet want to
benefit from the updates. (Or depend on automated updates via some vendor
package management system.) If we can ensure that with pytz in the stdlib,
updates to the Olson d
>
> When people use pytz they have to reinstall pytz too if thet want to
> benefit from the updates. (Or depend on automated updates via some vendor
> package management system.) If we can ensure that with pytz in the stdlib,
> updates to the Olson database can be installed just as easily as before
On 30/09/2012 20:53, MRAB wrote:
That's what UTC is for! :-)
I think that it would be a good idea to provide a database with the
release plus a tool for updating it, the updates being announced by
email or RSS, and the ability to use the system's database if there's
one.
Very naive extremely s
On 2012-09-30 19:55, Serhiy Storchaka wrote:
On 30.09.12 16:15, Antoine Pitrou wrote:
Probably, but for most purposes I would guess a 2-year old database is
still good enough? After all, you don't see many people complaining
about the outdated Unicode database that is hard-wired in past Pythons.
On Sun, 30 Sep 2012 22:35:54 +0300
Serhiy Storchaka wrote:
> On 30.09.12 22:24, Antoine Pitrou wrote:
> > Just because some governments have erratic policies shouldn't be a
> > reason for residents of other countries not to enjoy the benefits of
> > their stable timezones.
>
> This is similar to
On 30.09.12 22:24, Antoine Pitrou wrote:
Just because some governments have erratic policies shouldn't be a
reason for residents of other countries not to enjoy the benefits of
their stable timezones.
This is similar to ascii-chauvinism. ;-)
___
Pyt
On Sun, 30 Sep 2012 21:55:34 +0300
Serhiy Storchaka wrote:
> On 30.09.12 16:15, Antoine Pitrou wrote:
> > Probably, but for most purposes I would guess a 2-year old database is
> > still good enough? After all, you don't see many people complaining
> > about the outdated Unicode database that is h
On 30.09.12 16:15, Antoine Pitrou wrote:
Probably, but for most purposes I would guess a 2-year old database is
still good enough? After all, you don't see many people complaining
about the outdated Unicode database that is hard-wired in past Pythons.
In 2011 Ukrainian timezone data was changed
On Sun, Sep 30, 2012 at 8:33 AM, Benjamin Peterson wrote:
> 2012/9/30 Xavier Morel :
> > But at worst, an outdated unicode database will be missing data right?
> >
> > Doesn't an outdated timezone db have the risk of returning *incorrect*
> data?
>
> Unicode updates also include corrections; howev
2012/9/30 Xavier Morel :
> But at worst, an outdated unicode database will be missing data right?
>
> Doesn't an outdated timezone db have the risk of returning *incorrect* data?
Unicode updates also include corrections; however, it seems there are
not significant enough or about obscure enough sc
On Sun, 30 Sep 2012 15:30:04 +0200, Xavier Morel
wrote:
> On 2012-09-30, at 15:15 , Antoine Pitrou wrote:
>
> > On Sun, 30 Sep 2012 15:10:06 +0200
> > Dirkjan Ochtman wrote:
> >> On Sun, Sep 30, 2012 at 3:03 PM, Antoine Pitrou
> >> wrote:
> >>> Can't we simply include the Olson database in Wi
On 2012-09-30, at 15:15 , Antoine Pitrou wrote:
> On Sun, 30 Sep 2012 15:10:06 +0200
> Dirkjan Ochtman wrote:
>> On Sun, Sep 30, 2012 at 3:03 PM, Antoine Pitrou wrote:
>>> Can't we simply include the Olson database in Windows installers?
>>
>> We probably can, but the problem is that it's updat
On Sun, Sep 30, 2012 at 11:15 PM, Antoine Pitrou wrote:
> On Sun, 30 Sep 2012 15:10:06 +0200
> Dirkjan Ochtman wrote:
>> On Sun, Sep 30, 2012 at 3:03 PM, Antoine Pitrou wrote:
>> > Can't we simply include the Olson database in Windows installers?
>>
>> We probably can, but the problem is that it
On Sun, 30 Sep 2012 15:10:06 +0200
Dirkjan Ochtman wrote:
> On Sun, Sep 30, 2012 at 3:03 PM, Antoine Pitrou wrote:
> > Can't we simply include the Olson database in Windows installers?
>
> We probably can, but the problem is that it's updated quite often (for
> example, in 2011, there were about
On Sun, Sep 30, 2012 at 3:03 PM, Antoine Pitrou wrote:
> Can't we simply include the Olson database in Windows installers?
We probably can, but the problem is that it's updated quite often (for
example, in 2011, there were about 14 releases; in 2009, there were
21). So you'd want to have a mechan
On Sun, 30 Sep 2012 14:47:28 +0200
Lennart Regebro wrote:
> With 3.3 out, it's time to bring up something for 3.4. And it's about pytz
> and stdlib, basically. And we have been over that again, but I have a
> proposal anyway.
>
> The problem with including pytz in the stdlib is that it contains t
Am 30.09.2012 14:47, schrieb Lennart Regebro:
> What do you say? Is this a path worth pursuing?
+1
I'm eager to read your PEP!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mai
On Sun, Sep 30, 2012 at 2:47 PM, Lennart Regebro wrote:
> What do you say? Is this a path worth pursuing?
+1. It's the kind of low-level thing that should be solved in the
stdlib as far as possible, and the pytz interface is as stable as the
stdlib's.
Cheers,
Dirkjan
___
With 3.3 out, it's time to bring up something for 3.4. And it's about pytz
and stdlib, basically. And we have been over that again, but I have a
proposal anyway.
The problem with including pytz in the stdlib is that it contains the
tz/zoneinfo/Olson database, and it updates much more often than Py
78 matches
Mail list logo
