[issue24979] Allow timezone offsets greater than 24 hours
TJ added the comment: Thanks for the pointer to #5288. Happy to consolidate there. In my reading of #5094 (from which I pulled your RFC 2822 reference), the justification I found was "For the allowable range, follow the datetime docs as someone might be relying on that specification already". But this didn't explain why it was in the spec in the first place, and that is the decision I thought was arbitrary, not the decision to maintain the restriction. Splitting hairs at this point. Looking forward to the restriction being removed. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24979> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24979] Allow timezone offsets greater than 24 hours
New submission from TJ:
The datetime module only supports timezone offsets within 24 hours of UTC:
https://docs.python.org/3/library/datetime.html#datetime.tzinfo.utcoffset
This seems like an arbitrary restriction, and prevents the library from being
used in arbitrary timezone translations. For various reasons, one might need to
start a new day (perhaps to implement some business logic) during the regular
day. Depending on when/where this is, the effective offset can easily be
greater than 24 hours.
>>> import datetime
>>> import pytz
>>> dt = pytz.utc.localize(datetime.datetime.utcnow())
>>> dt
datetime.datetime(2015, 8, 31, 23, 30, 55, 590037, tzinfo=)
>>> tz = pytz.timezone('Pacific/Auckland_Custom')
>>> dt.astimezone(tz)
datetime.datetime(2015, 9, 2, 4, 30, 55, 590037, tzinfo=)
>>> dt_local = datetime.datetime.now()
>>> tz.localize(dt_local)
.../python2.7/site-packages/pytz/tzinfo.py in localize(self, dt, is_dst)
314 loc_dt = tzinfo.normalize(dt.replace(tzinfo=tzinfo))
315 if loc_dt.replace(tzinfo=None) == dt:
--> 316 possible_loc_dt.add(loc_dt)
317
318 if len(possible_loc_dt) == 1:
ValueError: tzinfo.utcoffset() returned 1440; must be in -1439 .. 1439
Note that although only offsets within 24 hours are supported, it seems to be
possible to use astimezone() with arbitrary offsets. So perhaps we gain
consistency in removing the restriction altogether?
This would not be unprecedented. RFC 2822 allows any offset
representable as HHMM: "the zone MUST be within the range -9959
through +9959" Section 3.3 of http://tools.ietf.org/html/rfc2822.html
--
components: Library (Lib)
messages: 249482
nosy: tjhnson
priority: normal
severity: normal
status: open
title: Allow timezone offsets greater than 24 hours
type: enhancement
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue24979>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22534] Possible Memory Leak with 'shelve'
TJ added the comment:
Thanks for the help. For my linux box, I have no issue. This is Ubuntu 13.10:
Linux localhost 3.11.0-26-generic #45-Ubuntu SMP Tue Jul 15 04:02:06 UTC
2014 x86_64 x86_64 x86_64 GNU/Linux
2.7.5+ (default, Feb 27 2014, 19:37:08)
[GCC 4.8.1]
However, I'm still getting issues with my other box, which is Mac OS. I think I
have the relevant info here (let me know if we need additional info):
[10:55:00] ~$ sw_vers -productVersion
10.9.2
[10:55:10] ~$ python -c import sys; print sys.version
2.7.8 (default, Aug 21 2014, 20:13:48)
[GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)]
[10:55:57] ~$ python -c import anydbm;d = anydbm.open('bla',
'c');print(type(d))
class 'bsddb._DBWithCursor'
[10:56:05] ~$ cat leaktest.py
import anydbm
while True:
d = anydbm.open('bla', 'c')
d.close()
[10:56:10] ~$ python leaktest.py
[1] 99030
[10:56:18] ~$ ps -o pid,rss,vsz,command -p 99030
PIDRSS VSZ COMMAND
99030 481928 3010600 python leaktest.py
[10:56:56] ~$ ps -o pid,rss,vsz,command -p 99030
PIDRSS VSZ COMMAND
99030 3985920 6516788 python leaktest.py
[11:01:10] ~$ # After 5 minutes, top shows MEM as 13G
[11:01:23] ~$ ps -o pid,rss,vsz,command -p 99030
PIDRSS VSZ COMMAND
99030 13891152 16429156 python leaktest.py
Those numbers are stable on my Linux box, and ever growing on Mac.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22534
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22534] bsddb memory leak on Mac OS X 10.9
TJ added the comment: No issue with 3.4 on the Mac box. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22534 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22534] bsddb memory leak on Mac OS X 10.9
TJ added the comment: I should have mentioned that this a Macports environment. So python, bsddb all come from there. Looks like that might be the culprit. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22534 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22534] bsddb memory leak with MacPorts bdb 4.6
TJ added the comment: For future visitors, here is the MacPorts issue: https://trac.macports.org/ticket/45247 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22534 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22534] Possible Memory Leak with 'shelve'
New submission from TJ:
The following code causes memory usage to grow excessively.
'''
import shelve
def func():
for i in range(100):
sh = shelve.open('blah')
sh.close()
func()
'''
--
components: Library (Lib)
messages: 228127
nosy: tjhnson
priority: normal
severity: normal
status: open
title: Possible Memory Leak with 'shelve'
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22534
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22534] Possible Memory Leak with 'shelve'
TJ added the comment: Put it in the while loop. Same result. Memory usage grows about 1 GiB per minute. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22534 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7437] OS X 2.6.4 installer fails on 10.3 with two corrupted file names, ignored on 10.4
TJ Sullivan tjsu...@gmail.com added the comment: Install was successful. PLease find the attachment with the test results you asked for. Thank you very much for making the fix to the package installer -- Added file: http://bugs.python.org/file16035/install test results.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7437 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7437] OS X 2.6.4 installer fails on 10.3 with two corrupted file names, ignored on 10.4
TJ Sullivan tjsu...@gmail.com added the comment: I would be happy to test the new package for you. I am running 10.3.9 and Had attempted to install 2.6.4 recently without realizing it, so my terminal version is 2.6.4 but idle and back at 2.5. email me if you want me to test it for you. -- nosy: +tjsulli ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7437 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4017] Tkinter cannot find Tcl/Tk on Mac OS X
TJ Usiyan [EMAIL PROTECTED] added the comment: same here -- nosy: +TJ ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4017 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
