Re: [Python-Dev] Status on PEP-431 Timezones
On Wed, Apr 8, 2015 at 9:57 PM, Isaac Schwabacher ischwabac...@wisc.edu wrote: On 15-04-08, Lennart Regebro wrote: === Stdlib option 2: A datetime _is_dst flag === By having a flag on the datetime instance that says this is in DST or not the timezone implementation can be kept simpler. Storing the offset itself instead of a flag makes things conceptually cleaner. The concept would be pretty much the same, but yes, you would be able to save lookups in the dst() call, so that's a benefit. I was planning on storing the dst() offset at least lazily, but I'm not sure that means we can get rid of the flag. As an added bonus, you get a representation that's still meaningful when time changes happen for political rather than DST reasons. That's a good point. Although you would still have to use the is_dst flag to choose in that case, even if neither or both is actually DST. Unless we come up with another name for that flag, which I don't think is important. //Lennart ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status on PEP-431 Timezones
On Wed, Apr 8, 2015 at 6:52 PM, Isaac Schwabacher ischwabac...@wisc.edu wrote: So storing the offset and storing a flag are not two alternative solutions to the same problem- these are two solutions to two different problems. I'm viewing a time zone as a map from UTC to local time; for example, America/Chicago is a time zone. I'm not proposing storing the offset as an alternative to storing the *time zone*, I'm proposing it as an alternative to storing whether a given time is DST or not. When you are proposing to store something, you also need to specify where you are proposing to store it. In the current design, local time information is stored in the datetime object and the rules that govern UTC to local mapping (and back) are stored in the tzinfo object. The implementors of concrete tzinfo subclasses are supposed to have access to time zone rules and implement utcoffset(dt), together with dst(dt) and tzname(dt) methods. Storing isdst in the datetime object would allow utcoffset(dt) to distinguish between 1:30AM before clock change and 1:30AM after. Where do you propose to store the offset? If you store it in dt, why would you need the tzinfo? We really don't care whether a time is DST or not; You may not care about it, but current tzinfo interface and tzinfo.fromutc(dt) method do. Whatever new features are added to the standard library, they cannot break existing uses. This means that whatever concrete tzinfo implementations we add to stdlib, they must provide an implementation of tzinfo.dst(dt) method. So our times would look like 2013-11-03 01:30:00-0500 America/Chicago and an hour later, 2013-11-03 01:30:00-0600 America/Chicago. And all of that information is stored in the datetime object. I don't think this is what most people would expect $ TZ=America/Chicago date Wed Apr 8 18:26:01 CDT 2015 or $ TZ=America/Chicago date +%c %z Wed 08 Apr 2015 06:27:09 PM CDT -0500 and not have location as a part of their timestamps. Regardless, whatever the proposal to add timezones to stdlib will end up being, it must include the ability to implement an equivalent of UNIX date command shown above. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status on PEP-431 Timezones
On 15-04-08, Lennart Regebro wrote: === Stdlib option 2: A datetime _is_dst flag === By having a flag on the datetime instance that says this is in DST or not the timezone implementation can be kept simpler. Storing the offset itself instead of a flag makes things conceptually cleaner. You get a representation that's slightly harder to construct from the sorts of information you have lying around (tz name, naive datetime, is_dst flag) but is no harder to construct *and* validate, and then is easier to work with and harder to misuse. As an added bonus, you get a representation that's still meaningful when time changes happen for political rather than DST reasons. Pros: - tzinfo.utcoffset() and local-UTC conversions don't require zoneinfo access. - it's harder to represent I know this time is DST but I don't know what tz it's in [I put this in pro because I don't see how this kind of ambiguity can lead to anything but trouble, but ymmv] - this representation is meaningful regardless of whether a time zone has DST - this representation meaningfully disambiguates across time changes not resulting from DST Cons: - tzinfo.dst() requires zoneinfo access - tzinfo.tzname() requires zoneinfo access IF you want those horrible ambiguous abbreviations (is CST America/Chicago or America/Havana?) [I really wanted to put this in pro] - (datetime, offset, tz) triples require validation [but so do (datetime, is_dst, tz) triples, even though it's easy to pretend they don't] - constructing an aware datetime from a naive one, an is_dst flag, and a time zone requires zoneinfo access [but this is needed for the validation step anyway] On 15-04-08, Alexander Belopolsky wrote: With datetime, we also have a problem that POSIX APIs don't have to deal with: local time arithmetics. What is t + timedelta(1) when t falls on the day before DST change? How would you set the isdst flag in the result? It's whatever time comes 60*60*24 seconds after t in the same time zone, because the timedelta class isn't expressive enough to represent anything but absolute time differences (nor should it be, IMO). But it might make sense to import dateutil.relativedelta or mxDateTime.RelativeDateTime into the stdlib to make relative time differences (same local time on the next day, for instance) possible. ijs ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status on PEP-431 Timezones
On Wed, Apr 8, 2015 at 8:11 PM, Alex Lord alexml...@gmail.com wrote: Newb question time, what's BoF http://en.wikipedia.org/wiki/Birds_of_a_feather_%28computing%29 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status on PEP-431 Timezones
Newb question time, what's BoF On Wed, Apr 8, 2015 at 7:31 PM, Alexander Belopolsky alexander.belopol...@gmail.com wrote: On Wed, Apr 8, 2015 at 6:52 PM, Isaac Schwabacher ischwabac...@wisc.edu wrote: So storing the offset and storing a flag are not two alternative solutions to the same problem- these are two solutions to two different problems. I'm viewing a time zone as a map from UTC to local time; for example, America/Chicago is a time zone. I'm not proposing storing the offset as an alternative to storing the *time zone*, I'm proposing it as an alternative to storing whether a given time is DST or not. When you are proposing to store something, you also need to specify where you are proposing to store it. In the current design, local time information is stored in the datetime object and the rules that govern UTC to local mapping (and back) are stored in the tzinfo object. The implementors of concrete tzinfo subclasses are supposed to have access to time zone rules and implement utcoffset(dt), together with dst(dt) and tzname(dt) methods. Storing isdst in the datetime object would allow utcoffset(dt) to distinguish between 1:30AM before clock change and 1:30AM after. Where do you propose to store the offset? If you store it in dt, why would you need the tzinfo? We really don't care whether a time is DST or not; You may not care about it, but current tzinfo interface and tzinfo.fromutc(dt) method do. Whatever new features are added to the standard library, they cannot break existing uses. This means that whatever concrete tzinfo implementations we add to stdlib, they must provide an implementation of tzinfo.dst(dt) method. So our times would look like 2013-11-03 01:30:00-0500 America/Chicago and an hour later, 2013-11-03 01:30:00-0600 America/Chicago. And all of that information is stored in the datetime object. I don't think this is what most people would expect $ TZ=America/Chicago date Wed Apr 8 18:26:01 CDT 2015 or $ TZ=America/Chicago date +%c %z Wed 08 Apr 2015 06:27:09 PM CDT -0500 and not have location as a part of their timestamps. Regardless, whatever the proposal to add timezones to stdlib will end up being, it must include the ability to implement an equivalent of UNIX date command shown above. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/alexmlord%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status on PEP-431 Timezones
On Thu, Apr 9, 2015 at 1:31 AM, Alexander Belopolsky alexander.belopol...@gmail.com wrote: Storing isdst in the datetime object would allow utcoffset(dt) to distinguish between 1:30AM before clock change and 1:30AM after. Where do you propose to store the offset? If you store it in dt, why would you need the tzinfo? Because otherwise you don't know what tzinfo the datetime uses, and you need to know that if you add or subtract a timedelta, or compare with another datetime. Regardless, whatever the proposal to add timezones to stdlib will end up being, it must include the ability to implement an equivalent of UNIX date command shown above. That's a strftime() issue, I think that issue is already solved. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status on PEP-431 Timezones
On Thu, Apr 9, 2015 at 8:32 AM, Alexander Belopolsky alexander.belopol...@gmail.com wrote: A named offset is an abbreviation such as UTC, EST, MSK, MSD which (at any given time) corresponds to a fixed offset from UTC. That assumes the abbreviations are unique. They're not. Just this morning I had to explain to a new student of mine that no, my time zone is not EST = New York time, it's actually EST = Melbourne time. Granted, most of the time New York and Melbourne are opposite on DST, so one will be EST and one EDT, but that trick won't always help you. (BTW, thanks Lennart for your Blame it on Caesar PyCon talk. I linked my student to it as a for further information resource. Good fun, and a great summary of why political time is such a minefield.) If this proposal goes through, in some form or another, will there be One Obvious Way to do timezone-aware calculations in Python? That would definitely be an improvement. ChrisA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status on PEP-431 Timezones
On Wed, Apr 8, 2015 at 7:37 PM, Carl Meyer c...@oddbird.net wrote: Hi Lennart, On 04/08/2015 09:18 AM, Lennart Regebro wrote: I wrote PEP-431 two years ago, and never got around to implement it. This year I got some renewed motivation after Berker Peksağ made an effort of implementing it. I'm planning to work more on this during the PyCon sprints, and also have a BoF session or similar during the conference. Anyone interested in a session on this, mail me and we'll set up a time and place! I'm interested in the topic, and would probably attend a BoF at PyCon. Cool! So is adopting pytz's expanded API into the stdlib really a big problem? Maybe, maybe not. But that API is also needlessly complicated, precisely because it's working around the limitations of datetime.tzinfo. In the PEP I remove those limitations but keep the simpler API. With a solution based on how pytz does it, I don't think that's possible. Is this really adequate? pytz's implementation handles far more than is DST or not, it also correctly handles historical timezone changes. How would those be handled under this proposal? Those would still be handled. The flag is only to flag if it's DST or not in a timestamp that is otherwise ambiguous. //Lennart ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status on PEP-431 Timezones
On Wed, Apr 8, 2015 at 3:57 PM, Isaac Schwabacher ischwabac...@wisc.edu wrote: On 15-04-08, Lennart Regebro wrote: === Stdlib option 2: A datetime _is_dst flag === By having a flag on the datetime instance that says this is in DST or not the timezone implementation can be kept simpler. Storing the offset itself instead of a flag makes things conceptually cleaner. It is important to distinguish two notions that unfortunately both called a time zone. For lack of better terms, let me define named offsets and locations as follows: A named offset is an abbreviation such as UTC, EST, MSK, MSD which (at any given time) corresponds to a fixed offset from UTC. Since at different historical times, the same abbreviation such as MSK may correspond to a different offset, you cannot always derive one from another and extended struct tm provides fields for both: tm_gmtoff and tm_zone. A location is a name of geographical entity such as America/New_York which follows the same timekeeping rules. The isdst flag is necessary when you know the location and local time and want to find out the corresponding UTC time. In many locations, there is one our every year when knowing local time is not enough because the same local time corresponds to two different UTC times. This happens in the US when we move the clock back one hour some day in the Fall. UTC time marches on, but local time repeats the same hour. So in order to know what 01:30 AM is in New York, you also need to know whether it is before we moved the clocks back or after. So storing the offset and storing a flag are not two alternative solutions to the same problem- these are two solutions to two different problems. .. On 15-04-08, Alexander Belopolsky wrote: With datetime, we also have a problem that POSIX APIs don't have to deal with: local time arithmetics. What is t + timedelta(1) when t falls on the day before DST change? How would you set the isdst flag in the result? It's whatever time comes 60*60*24 seconds after t in the same time zone, because the timedelta class isn't expressive enough to represent anything but absolute time differences (nor should it be, IMO). This is not what most uses expect. The expect datetime(y, m, d, 12, tzinfo=New_York) + timedelta(1) to be datetime(y, m, d+1, 12, tzinfo=New_York) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status on PEP-431 Timezones
On Wed, Apr 8, 2015 at 7:32 PM, Chris Angelico ros...@gmail.com wrote: On Thu, Apr 9, 2015 at 8:32 AM, Alexander Belopolsky alexander.belopol...@gmail.com wrote: A named offset is an abbreviation such as UTC, EST, MSK, MSD which (at any given time) corresponds to a fixed offset from UTC. That assumes the abbreviations are unique. They're not. Just this morning I had to explain to a new student of mine that no, my time zone is not EST = New York time, it's actually EST = Melbourne time. Granted, most of the time New York and Melbourne are opposite on DST, so one will be EST and one EDT, but that trick won't always help you. I should have been more precise in my definitions. A named offset is a pair (tm_gmtoff, tm_zone). Given a location and a UTC time (UNIX timestamp), you should be able to produce a named offset. $ TZ=Australia/Melbourne date -d @1428536256 +%z %Z +1000 EST The name part is usually redundant, but convenient for human readers. The opposite is not true: you cannot derive location from either or both parts. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status on PEP-431 Timezones
On 15-04-08, Alexander Belopolsky wrote:
On Wed, Apr 8, 2015 at 3:57 PM, Isaac Schwabacher ischwabac...@wisc.edu
ischwabac...@wisc.edu wrote:
On 15-04-08, Lennart Regebro wrote:
=== Stdlib option 2: A datetime _is_dst flag ===
By having a flag on the datetime instance that says this is in DST or
not
the timezone implementation can be kept simpler.
Storing the offset itself instead of a flag makes things conceptually
cleaner.
It is important to distinguish two notions that unfortunately both called a
time zone. For lack
of better terms, let me define named offsets and locations as follows:
A named offset is an abbreviation such as UTC, EST, MSK, MSD which (at any
given time)
corresponds to a fixed offset from UTC. Since at different historical times,
the same abbreviation
such as MSK may correspond to a different offset, you cannot always derive
one from another
and extended struct tm provides fields for both: tm_gmtoff and tm_zone.
A location is a name of geographical entity such as America/New_York which
follows the sametimekeeping rules.
The isdst flag is necessary when you know the location and local time and
want to find out the
corresponding UTC time. In many locations, there is one our every year when
knowing local
time is not enough because the same local time corresponds to two different
UTC times.
This happens in the US when we move the clock back one hour some day in the
Fall. UTC time
marches on, but local time repeats the same hour. So in order to know what
01:30 AM is in New York,
you also need to know whether it is before we moved the clocks back or after.
So storing the offset and storing a flag are not two alternative
solutions to the same problem- these
are two solutions to two different problems.
I'm viewing a time zone as a map from UTC to local time; for example,
America/Chicago is a time zone. I'm not proposing storing the offset as an
alternative to storing the *time zone*, I'm proposing it as an alternative to
storing whether a given time is DST or not. We really don't care whether a time
is DST or not; we care about the local time and the offset, and we need the
time zone because otherwise we can't relate our time to other times. So our
times would look like 2013-11-03 01:30:00-0500 America/Chicago and an hour
later, 2013-11-03 01:30:00-0600 America/Chicago. And all of that information
is stored in the datetime object.
..
On 15-04-08, Alexander Belopolsky wrote:
With datetime, we also have a problem that POSIX APIs don#39;t have to
deal with: local time
arithmetics. What is t + timedelta(1) when t falls on the day before DST
change? How would
you set the isdst flag in the result?
It#39;s whatever time comes 60*60*24 seconds after t in the same time
zone, because the timedelta class isn#39;t expressive enough to represent
anything but absolute time differences (nor should it be, IMO).
This is not what most uses expect. The expect
datetime(y, m, d, 12, tzinfo=New_York) + timedelta(1)
to be
datetime(y, m, d+1, 12, tzinfo=New_York)
The current definition of datetime.timedelta doesn't allow any reasonable
definition of
datetime(2013, 11, 3, 23, 30, tz=zoneinfo('America/Chicago')) - datetime(2013,
11, 3, 0, 30, tz=zoneinfo('America/Chicago'))
other than timedelta(1) because the seconds field is not allowed to be more
than 60*60*24.
ijs
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ctypes module
On 8 April 2015 at 20:36, Maciej Fijalkowski fij...@gmail.com wrote: I presume the reason was that noone wants to maintain code for the case where there are no buildbots available and there is no development time available. You are free to put back in the files and see if they work (they might not), but such things are usually removed if they're a maintenance burden. I would be happy to assist you with finding someone willing to do commercial maintenance of ctypes for itanium, but asking python devs to do it for free is a bit too much. As a point of reference, even Red Hat dropped Itanium support for RHEL6+ - you have to go all the way back to RHEL5 to find a version we still support running on Itanium. For most of CPython, keeping it running on arbitrary architectures often isn't too difficult, as libc abstracts away a lot of the hardware details. libffi (and hence ctypes) are notable exceptions to that :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ctypes module
I presume the reason was that noone wants to maintain code for the case where there are no buildbots available and there is no development time available. You are free to put back in the files and see if they work (they might not), but such things are usually removed if they're a maintenance burden. I would be happy to assist you with finding someone willing to do commercial maintenance of ctypes for itanium, but asking python devs to do it for free is a bit too much. Cheers, fijal On Tue, Apr 7, 2015 at 9:58 PM, Cristi Fati cristifa...@gmail.com wrote: Hi all, Not sure whether you got this question, or this is the right distribution list: Intel has deprecated Itanium architecture, and Windows also deprecated its versions(currently 2003 and 2008) that run on IA64. However Python (2.7.3) is compilable on Windows IA64, but ctypes module (1.1.0) which is now part of Python is not (the source files have been removed). What was the reason for its disablement? I am asking because an older version of ctypes (1.0.2) which came as a separate extension module (i used to compile it with Python 2.4.5) was available for WinIA64; i found (and fixed) a nasty buffer overrun in it. Regards, Cristi Fati. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/fijall%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ctypes module
for the record libffi supports itanium officially (but as usual I'm very skeptical how well it works on less used platforms) https://sourceware.org/libffi/ On Wed, Apr 8, 2015 at 1:32 PM, Nick Coghlan ncogh...@gmail.com wrote: On 8 April 2015 at 20:36, Maciej Fijalkowski fij...@gmail.com wrote: I presume the reason was that noone wants to maintain code for the case where there are no buildbots available and there is no development time available. You are free to put back in the files and see if they work (they might not), but such things are usually removed if they're a maintenance burden. I would be happy to assist you with finding someone willing to do commercial maintenance of ctypes for itanium, but asking python devs to do it for free is a bit too much. As a point of reference, even Red Hat dropped Itanium support for RHEL6+ - you have to go all the way back to RHEL5 to find a version we still support running on Itanium. For most of CPython, keeping it running on arbitrary architectures often isn't too difficult, as libc abstracts away a lot of the hardware details. libffi (and hence ctypes) are notable exceptions to that :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status on PEP-431 Timezones
On Wed, Apr 8, 2015 at 11:18 AM, Lennart Regebro rege...@gmail.com wrote: === Stdlib option 2: A datetime _is_dst flag === By having a flag on the datetime instance that says this is in DST or not the timezone implementation can be kept simpler. I floated this idea [1] back in the days when we discussed the datetime.timestamp() method. The attraction was that such API would be familiar to the users of POSIX mktime and struct tm, but the history have shown that these POSIX APIs were insufficient in many situations and struct tm was extended by may libraries to include non-standard tm_gmtoff and tm_zone fields. With datetime, we also have a problem that POSIX APIs don't have to deal with: local time arithmetics. What is t + timedelta(1) when t falls on the day before DST change? How would you set the isdst flag in the result? [1] http://bugs.python.org/issue2736#msg124237 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status on PEP-431 Timezones
Hi Lennart, On 04/08/2015 09:18 AM, Lennart Regebro wrote: I wrote PEP-431 two years ago, and never got around to implement it. This year I got some renewed motivation after Berker Peksağ made an effort of implementing it. I'm planning to work more on this during the PyCon sprints, and also have a BoF session or similar during the conference. Anyone interested in a session on this, mail me and we'll set up a time and place! I'm interested in the topic, and would probably attend a BoF at PyCon. Comments below: If anyone is interested in the details of the problem, this is it. The big problem is the ambiguous times, like 02:30 a time when you move the clock back one hour, as there are two different 02:30's that day. I wrote down my experiences with looking into and trying to implement several different solutions. And the problem there is actually how to tell the datetime if it is before or after the changeover. == How others have solved it == === dateutil.tz: Ignore the problem === dateutil.tz simply ignores the problems with ambiguous datetimes, keeping them ambiguous. === pytz: One timezone instance per changeover === Pytz implements ambiguous datetimes by having one class per timezone. Each change in the UTC offset changes, either because of a DST changeover, or because the timezone changes, is represented as one instance of the class. All instances are held in a list which is a class attribute of the timezone class. You flag in which DST changeover you are by uising different instances as the datetimes tzinfo. Since the timezone this way knows if it is DST or not, the datetime as a whole knows if it's DST or not. Benefits: - Only known possible implementation without modifying stdlib, which of course was a requirement, as pytz is a third-party library. - DST offset can be quickly returned, as it does not need to be calculated. Drawbacks: - A complex and highly magical implementation of timezones that is hard to understand. - Required new normalize()/localize() functions on the timezone, and hence the API is not stdlib's API. - Hundreds of instances per timezone means slightly more memory usage. == Options for PEP 431 == === Stdlib option 0: Ignore it === I don't think this is an option, really. Listed for completness. === Stdlib option 1: One timezone instance per changeover === Option 1 is to do it like pytz, have one timezone instance per changeover. However, this is likely not possible to do without fundamentally changing the datetime API, or making it very hard to use. For example, when creating a datetime instance and passing in a tzinfo today this tzinfo is just attached to the datetime. But when having multiple instances of tzinfos this means you have to select the correct one to pass in. pytz solves this with the .localize() method, which let's the timezone class choose which instance to pass in. We can't pass in the timezone class into datetime(), because that would require datetime.__new__ to create new datetimes as a part of the timezone arithmetic. These in turn, would create new datetimes in __new__ as a part of the timezone arithmetic, which in turn, yeah, you get it... I haven't been able to solve that issue without either changing the API/usage, or getting infinite recursions. Benefits: - Proven soloution through pytz. - Fast dst() call. Drawbacks: - Trying to use this technique with the current API tends to create infinite recursions. It seems to require big API changes. - Slow datetime() instance creation. I think proven solution is a significant benefit. Today, anyone who is serious about correct timezone handling in Python is almost certainly using pytz. So is adopting pytz's expanded API into the stdlib really a big problem? It probably presents _fewer_ back-compatibility issues with real-world code than taking a different approach from pytz would. === Stdlib option 2: A datetime _is_dst flag === By having a flag on the datetime instance that says this is in DST or not the timezone implementation can be kept simpler. Is this really adequate? pytz's implementation handles far more than is DST or not, it also correctly handles historical timezone changes. How would those be handled under this proposal? You also have to either calculate if the datetime is in a DST or not either when creating it, which demands datetime object creations, and causes infinite recursions, or you have to calculate it when needed, which means you can get Ambiguous date time errors at unexpected times later. Also, when trying to implement this, I get bogged down in the complexities of how tzinfo and datetime is calling each other back and forth, and when to pass in the current is_dst and when to pass in the the desired is_dst, etc. The API and current implementation is not designed with this case in mind, and it gets very tricky. Benefits: - Simpler tzinfo()
Re: [Python-Dev] ctypes module
Hi all, thank you for your responses. Apparently i was wrong in my previous email, ctypes (1.0.1 or 1.0.2) didn't have support for WinIA64 (libffi), there was an in-house implementation. However we are using the IA64 module extensively (including to successfully call LsaLogonUser). a much simpler example: Python 2.7.3 (default, Oct 22 2014, 12:21:16) [MSC v.1600 64 bit (Itanium)] on win32 Type help, copyright, credits or license for more information. import ctypes ctypes.cdll.kernel32.GetTickCount() -79897956 On Wed, Apr 8, 2015 at 3:17 PM, Maciej Fijalkowski fij...@gmail.com wrote: for the record libffi supports itanium officially (but as usual I'm very skeptical how well it works on less used platforms) https://sourceware.org/libffi/ On Wed, Apr 8, 2015 at 1:32 PM, Nick Coghlan ncogh...@gmail.com wrote: On 8 April 2015 at 20:36, Maciej Fijalkowski fij...@gmail.com wrote: I presume the reason was that noone wants to maintain code for the case where there are no buildbots available and there is no development time available. You are free to put back in the files and see if they work (they might not), but such things are usually removed if they're a maintenance burden. I would be happy to assist you with finding someone willing to do commercial maintenance of ctypes for itanium, but asking python devs to do it for free is a bit too much. As a point of reference, even Red Hat dropped Itanium support for RHEL6+ - you have to go all the way back to RHEL5 to find a version we still support running on Itanium. For most of CPython, keeping it running on arbitrary architectures often isn't too difficult, as libc abstracts away a lot of the hardware details. libffi (and hence ctypes) are notable exceptions to that :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Status on PEP-431 Timezones
Hi! I wrote PEP-431 two years ago, and never got around to implement it. This year I got some renewed motivation after Berker Peksağ made an effort of implementing it. I'm planning to work more on this during the PyCon sprints, and also have a BoF session or similar during the conference. Anyone interested in a session on this, mail me and we'll set up a time and place! //Lennart -- If anyone is interested in the details of the problem, this is it. The big problem is the ambiguous times, like 02:30 a time when you move the clock back one hour, as there are two different 02:30's that day. I wrote down my experiences with looking into and trying to implement several different solutions. And the problem there is actually how to tell the datetime if it is before or after the changeover. == How others have solved it == === dateutil.tz: Ignore the problem === dateutil.tz simply ignores the problems with ambiguous datetimes, keeping them ambiguous. === pytz: One timezone instance per changeover === Pytz implements ambiguous datetimes by having one class per timezone. Each change in the UTC offset changes, either because of a DST changeover, or because the timezone changes, is represented as one instance of the class. All instances are held in a list which is a class attribute of the timezone class. You flag in which DST changeover you are by uising different instances as the datetimes tzinfo. Since the timezone this way knows if it is DST or not, the datetime as a whole knows if it's DST or not. Benefits: - Only known possible implementation without modifying stdlib, which of course was a requirement, as pytz is a third-party library. - DST offset can be quickly returned, as it does not need to be calculated. Drawbacks: - A complex and highly magical implementation of timezones that is hard to understand. - Required new normalize()/localize() functions on the timezone, and hence the API is not stdlib's API. - Hundreds of instances per timezone means slightly more memory usage. == Options for PEP 431 == === Stdlib option 0: Ignore it === I don't think this is an option, really. Listed for completness. === Stdlib option 1: One timezone instance per changeover === Option 1 is to do it like pytz, have one timezone instance per changeover. However, this is likely not possible to do without fundamentally changing the datetime API, or making it very hard to use. For example, when creating a datetime instance and passing in a tzinfo today this tzinfo is just attached to the datetime. But when having multiple instances of tzinfos this means you have to select the correct one to pass in. pytz solves this with the .localize() method, which let's the timezone class choose which instance to pass in. We can't pass in the timezone class into datetime(), because that would require datetime.__new__ to create new datetimes as a part of the timezone arithmetic. These in turn, would create new datetimes in __new__ as a part of the timezone arithmetic, which in turn, yeah, you get it... I haven't been able to solve that issue without either changing the API/usage, or getting infinite recursions. Benefits: - Proven soloution through pytz. - Fast dst() call. Drawbacks: - Trying to use this technique with the current API tends to create infinite recursions. It seems to require big API changes. - Slow datetime() instance creation. === Stdlib option 2: A datetime _is_dst flag === By having a flag on the datetime instance that says this is in DST or not the timezone implementation can be kept simpler. You also have to either calculate if the datetime is in a DST or not either when creating it, which demands datetime object creations, and causes infinite recursions, or you have to calculate it when needed, which means you can get Ambiguous date time errors at unexpected times later. Also, when trying to implement this, I get bogged down in the complexities of how tzinfo and datetime is calling each other back and forth, and when to pass in the current is_dst and when to pass in the the desired is_dst, etc. The API and current implementation is not designed with this case in mind, and it gets very tricky. Benefits: - Simpler tzinfo() implementations. Drawbacks: - It seems likely that we must change some API's. - This in turn may affect the pytz implementation. Or not, hard to say. - The DST offset must use slow timezone calculations. However, since datetimes are immutable it can be a cached, lazy, one-time operation. === Stdlib option 3: UTC internal representation === Having UTC as the internal representation makes the whole issue go away. Datetimes are no longer ambiguous, except when creating, so checks need to be done during creation, but that should be possible without datetime creation in this case, resolving the infinite recursion problem. Benefits: - Problem solved. - Minimal API changes. Drawbacks: - Backwards compatibility with pickles. - Possible other backwards
Re: [Python-Dev] Status on PEP-431 Timezones
On Apr 8, 2015, at 12:37, Carl Meyer c...@oddbird.net wrote: Anyone interested in a session on this, mail me and we'll set up a time and place! I'm interested in the topic, and would probably attend a BoF at PyCon. I'm of a similar mind. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
