On Fri, Feb 26, 2010 at 3:59 PM, Lennart Regebro wrote:
> I'm worrying that adding such a
> thing to stdlib will do so in an unfinished state, and we'll just en
> up with yet another state of semi-brokenness.
I valid worry, and compelling.
As I've alluded to before, leaving it out and allowing a
On Fri, Feb 19, 2010 at 19:37, wrote:
>
> Lennart> I would like if we could look into making a timezone module
> Lennart> that works on Python 2.5 to 3.2 that uses system data...
>
> 2.5, 2.6 and 3.1 are completely off the radar screen at this point. The
> best you could hope for is that s
Lennart> I would like if we could look into making a timezone module
Lennart> that works on Python 2.5 to 3.2 that uses system data...
2.5, 2.6 and 3.1 are completely off the radar screen at this point. The
best you could hope for is that someone backports whatever is created for
2.7 or
On Fri, Feb 19, 2010 at 07:27, Stuart Bishop wrote:
>> In any case, since you want to make a version that can be included and
>> uses the timezone API, I guess that's a moot question until we have
>> that version. :)
>
> As I understand it dateutil pretty much already provides what I'm describing.
On Fri, Feb 19, 2010 at 12:11 PM, Lennart Regebro wrote:
> But is the "You don't have to install it" really such a big problem so
> that it's worth the other problems like platform incompatibilities and
> such?
I don't think there are any platform incompatibilities - it will work
as documented o
But is the "You don't have to install it" really such a big problem so
that it's worth the other problems like platform incompatibilities and
such?
In any case, since you want to make a version that can be included and
uses the timezone API, I guess that's a moot question until we have
that versio
On Fri, Feb 19, 2010 at 4:45 AM, Lennart Regebro wrote:
On Thu, Feb 18, 2010 at 22:42, "Martin v. Löwis" wrote:
That's not true. The registry is readable by any user, and the format is
fully documented.
Yes, but they use non-standard locations, and afaik, pytz does not
support it. If a stdli
On Thu, Feb 18, 2010 at 22:42, "Martin v. Löwis" wrote:
> That's not true. The registry is readable by any user, and the format is
> fully documented.
Yes, but they use non-standard locations, and afaik, pytz does not
support it. If a stdlib pytz would use this you would have to use
different tim
>> That information is also
>> available from the system on Mac OS and Windows.
>
> It is not available on Windows in any reasonable and useable form.
That's not true. The registry is readable by any user, and the format is
fully documented.
Regards,
Martin
__
On Thu, Feb 18, 2010 at 13:41, anatoly techtonik wrote:
> It will still require workarounds and bridges to make API in user
> scripts convenient, i.e.
>
> try:
> import pytz
> mydatetime = PytzDatetime()
> catch ImportError:
> mydatetime = ClassicDatetime()
Only if you want to work both with a
On Thu, Feb 18, 2010 at 11:29, Stuart Bishop wrote:
> I think a tzinfo implementation in the standard library that uses the system
> timezone database would be useful to a great many people, providing a
> standard way of mapping a string to a tzinfo instance.
Well, that wouldn't work on Windows,
On Thu, Feb 18, 2010 at 7:41 AM, anatoly techtonik wrote:
> It will still require workarounds and bridges to make API in user
> scripts convenient, i.e.
I'm not entirely sure what you intended the "It" to refer to here.
My take on this is that bundling a version of pytz in the standard
library w
On Tue, Feb 16, 2010 at 1:52 PM, Victor Stinner
wrote:
>> So far, Python timezone handling is far from "pythonic". There is no
>> function to get current UTC offset, (...)
>
> There is the time.timezone attribute: UTC offset in seconds.
It is correct only if DST is not in effect.
On Tue, Feb 16,
On Thu, Feb 18, 2010 at 4:38 PM, Lennart Regebro wrote:
If it doesn't solve a problem, it shouldn't be done, as it also is
going to create problems, because everything does. :)
I think a tzinfo implementation in the standard library that uses the system
timezone database would be useful to
-On [20100217 23:48], s...@pobox.com (s...@pobox.com) wrote:
>My guess is the data are updated several times per year, not the code. Can
>they not be separated?
The bulk of the original timezone package is data for the timezones. Last
year saw close to 26 releases for this.
--
Jeroen Ruigrok va
On Thu, Feb 18, 2010 at 03:48, Michael Foord wrote:
> Some of the Linux distributions *already* patch pytz to use the system
> information, which they keep updated separately.
Yes. And what problem does including pytz in the stdlib solve?
> That information is also
> available from the system on
On 17 February 2010 23:01, Lennart Regebro wrote:
> On Wed, Feb 17, 2010 at 23:46, wrote:
> >
> >Lennart> The timezone database is updated several times per year. You
> >Lennart> can *not* include it in the standard library.
> >
> > My guess is the data are updated several times per yea
s...@pobox.com writes:
> My guess is the data are updated several times per year, not the code.
> Can they not be separated?
AIUI this discussion is about getting the ‘pytz’ library into the Python
standard library. If the data is separate from the modules, the question
then becomes how users on
On Wed, Feb 17, 2010 at 23:46, wrote:
>
> Lennart> The timezone database is updated several times per year. You
> Lennart> can *not* include it in the standard library.
>
> My guess is the data are updated several times per year, not the code. Can
> they not be separated?
Yes, but that wo
Lennart> The timezone database is updated several times per year. You
Lennart> can *not* include it in the standard library.
My guess is the data are updated several times per year, not the code. Can
they not be separated?
Skip
___
Python-Dev
Defaulting to UTC is not a good idea, which is why relevant methods take an
argument to specify whether to be UTC (exact details are in the patch; don't
remember exact details).
On Feb 16, 2010 4:07 PM, "Greg Ewing" wrote:
Brett Cannon wrote:
> Issue 5094 already has a patch that is nearly comp
On Wed, Feb 17, 2010 at 12:32, Lennart Regebro wrote:
> These kinds of wrappers exist in dateutils.tz. It would be great if
> that type of functionality could get into Pytz as well. A sprint to do
> this and fix the issues in the tracker should solve the issues, I
> think. There is no need to move
On Tue, Feb 16, 2010 at 13:42, Dirkjan Ochtman wrote:
> On Tue, Feb 16, 2010 at 13:05, wrote:
>> Maybe an alternate sprint idea would be to incorporate dateutil into the
>> Python core: http://labix.org/python-dateutil
>>
>> Whoops... (just waking up - still need that first cup of coffee)
-On [20100217 03:19], Stuart Bishop (stu...@stuartbishop.net) wrote:
>The Debian, Ubuntu and I think Redhat packages all use the system
>zoneinfo database - there are hooks in there to support package
>maintainers that want to do this. This way the package can be included
>in the supported release
On Wed, Feb 17, 2010 at 09:15:25AM +0700, Stuart Bishop wrote:
>
> The Debian, Ubuntu and I think Redhat packages all use the system
> zoneinfo database - there are hooks in there to support package
> maintainers that want to do this.
Where RedHat == Fedora && EPEL packages for RHEL/Centos 5, yes
On Tue, Feb 16, 2010 at 11:18 PM, Tres Seaver wrote:
> Dirkjan Ochtman wrote:
>> On Tue, Feb 16, 2010 at 16:26, Tres Seaver wrote:
>>> Because timezones are defined politically, they change frequently. pytz
>>> is released frequently (multiple times per year) to accomodate those
>>> changes: I
Brett Cannon wrote:
Issue 5094 already has a patch that is nearly complete to provide a
default UTC object (and requisite changes to functions to no longer be
naive but to use UTC).
Are you sure it's really a good idea to default to UTC?
I thought it was considered a feature that datetime
obje
On Tue, Feb 16, 2010 at 02:38, anatoly techtonik wrote:
> Hello,
>
> So far, Python timezone handling is far from "pythonic". There is no
> function to get current UTC offset, intuitive API to get DST of
> current time zone and whenever it is active, no functions to work with
> internet timestamps
On 2/16/2010 11:15 AM, exar...@twistedmatrix.com wrote:
> On 03:43 pm, dirk...@ochtman.nl wrote:
> pytz includes its own timezone database. It doesn't use the system
> timezone data, even on Linux.
dateutil can use the system timezone data. See tzfile.
http://labix.org/python-dateutil#head-4e438
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dirkjan Ochtman wrote:
> On Tue, Feb 16, 2010 at 16:26, Tres Seaver wrote:
>> Because timezones are defined politically, they change frequently. pytz
>> is released frequently (multiple times per year) to accomodate those
>> changes: I can't see any
On 03:43 pm, dirk...@ochtman.nl wrote:
On Tue, Feb 16, 2010 at 16:26, Tres Seaver
wrote:
Because timezones are defined politically, they change frequently.
pytz
is released frequently (multiple times per year) to accomodate those
changes: �I can't see any way to preserve that flexibility if th
On Tue, Feb 16, 2010 at 16:26, Tres Seaver wrote:
> Because timezones are defined politically, they change frequently. pytz
> is released frequently (multiple times per year) to accomodate those
> changes: I can't see any way to preserve that flexibility if the
> package were part of stdlib.
By
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
s...@pobox.com wrote:
> Maybe an alternate sprint idea would be to incorporate dateutil into the
> Python core: http://labix.org/python-dateutil
>
> Whoops... (just waking up - still need that first cup of coffee)
>
> While incorporating dat
On Tue, Feb 16, 2010 at 13:05, wrote:
> Maybe an alternate sprint idea would be to incorporate dateutil into the
> Python core: http://labix.org/python-dateutil
>
> Whoops... (just waking up - still need that first cup of coffee)
>
> While incorporating dateutil into the core would be nice
Victor Stinner wrote:
> Hi,
>
> Le Tuesday 16 February 2010 11:38:05 anatoly techtonik, vous avez écrit :
>> So far, Python timezone handling is far from "pythonic". There is no
>> function to get current UTC offset, (...)
>
> There is the time.timezone attribute: UTC offset in seconds.
>
>> One
s...@pobox.com wrote:
> While incorporating dateutil into the core would be nice (in my opinion at
> least)
I believe that idea has come up before - as I recall, the major concern
was with the heuristic nature of some of the 'natural language' date
parsing. (I could be completely misremembering th
Maybe an alternate sprint idea would be to incorporate dateutil into the
Python core: http://labix.org/python-dateutil
Whoops... (just waking up - still need that first cup of coffee)
While incorporating dateutil into the core would be nice (in my opinion at
least), I was really thinking
Maybe an alternate sprint idea would be to incorporate dateutil into the
Python core: http://labix.org/python-dateutil
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.py
Hi,
Le Tuesday 16 February 2010 11:38:05 anatoly techtonik, vous avez écrit :
> So far, Python timezone handling is far from "pythonic". There is no
> function to get current UTC offset, (...)
There is the time.timezone attribute: UTC offset in seconds.
> One of the reasons I see is that date/ti
39 matches
Mail list logo
