Re: [Python-Dev] Status on PEP-431 Timezones

[Lennart Regebro]

There is plenty of time to book an open space now. I would prefer sometime
Saturday.  Any wishes?
___
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

[Alexander Belopolsky]

On Thu, Apr 9, 2015 at 11:59 AM, Isaac Schwabacher 
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?
>
> I propose to add an offset field to datetime.datetime. It should be set
> precisely when the tz field is set, and it should contain either a
> timedelta or an integer number of (possibly fractional) seconds, depending
> on what color the bikeshed gets painted. This is, IIUC, precisely where
> Lennart is proposing to store the is_dst flag.


Can you describe a situation where having isdst flag is not sufficient?

Note that in many applications you want to find the appropriate offset
knowing only local time and location, so requiring users to supply the
offset defeats the purpose of the time zone database.  In many
applications, the isdst flag can be hidden from the user.  For example, a
scheduling application can pretend that a repeated hour does not exist and
always assume that 01:30 AM is the first 01:30 AM.  (In many business
applications, it is a good idea anyways.)  Alternatively, a user attempting
to schedule an event at an ambiguous time can be presented with a warning
and a request to pick one of two possible times.  This would be a much
friendlier interface than the one always requiring the use to specify the
UTC offset.
___
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

[Isaac Schwabacher]

On 15-04-09, Alexander Belopolsky  wrote:
> 
> On Thu, Apr 9, 2015 at 11:59 AM, Isaac Schwabacher 
>  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?
> > 
> > I propose to add an offset field to datetime.datetime. It should be set 
> > precisely when the tz field is set, and it should contain either a 
> > timedelta or an integer number of (possibly fractional) seconds, depending 
> > on what color the bikeshed gets painted. This is, IIUC, precisely where 
> > Lennart is proposing to store the is_dst flag.
> 
> Can you describe a situation where having isdst flag is not sufficient?
> 
> Note that in many applications you want to find the appropriate offset 
> knowing only local time and location, so requiring users to supply the offset 
> defeats the purpose of the time zone database. In many applications, the 
> isdst flag can be hidden from the user. For example, a scheduling application 
> can pretend that a repeated hour does not exist and always assume that 01:30 
> AM is the first 01:30 AM. (In many business applications, it is a good idea 
> anyways.) Alternatively, a user attempting to schedule an event at an 
> ambiguous time can be presented with a warning and a request to pick one of 
> two possible times. This would be a much friendlier interface than the one 
> always requiring the use to specify the UTC offset.

I'm suggesting an internal representation, not a user interface. The only 
user-facing consequence of this internal representation would be exposing the 
offset to datetime.replace() and as a field on the object. All of the other 
interfaces that convert naive datetimes into aware datetimes would still use 
the is_dst flag as specified in the PEP. The intention is to make it easy to 
implement arithmetic and things like relative timedeltas.

But looking at datetime.h, which seems to be willing to sacrifice conceptual 
simplicity in order to pack a datetime into as few bytes in memory as possible, 
it seems like whatever made that a good idea makes this a bad one. :/

> > if someone passed you datetime(2013, 11, 3, 1, 30) without a time zone. 
> > astimezone assumes that the input naive time is UTC, which is not the case 
> > here.
> 
> No, it does not. Please read the documentation: "self must be aware 
> (self.tzinfo must not be None, and self.utcoffset() must not return None)."

Whoops, you're right. But that's even worse-- it doesn't give you a way to 
convert a naive datetime at all. Currently the only way from "2013-11-03 
01:30:00" to "2013-11-03 01:30:00-0500 America/Chicago" is still 
datetime.replace().

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

[Alexander Belopolsky]

On Thu, Apr 9, 2015 at 3:07 PM, Isaac Schwabacher 
wrote:

> > No, it does not. Please read the documentation: "self must be aware
> (self.tzinfo must not be None, and self.utcoffset() must not return None)."
>
> Whoops, you're right. But that's even worse-- it doesn't give you a way to
> convert a naive datetime at all. Currently the only way from "2013-11-03
> 01:30:00" to "2013-11-03 01:30:00-0500 America/Chicago" is still
> datetime.replace().


Well, you are right, but at least we do have a localtime utility hidden in
the email package:

>>> from datetime import *
>>> from email.utils import localtime
>>> print(localtime(datetime.now()))
2015-04-09 15:19:12.84-04:00

You can read  for the reasons it did not
make into datetime.
___
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

[Isaac Schwabacher]

On 15-04-08, Alexander Belopolsky  wrote:
> 
> On Wed, Apr 8, 2015 at 6:52 PM, Isaac Schwabacher  > 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?

I propose to add an offset field to datetime.datetime. It should be set 
precisely when the tz field is set, and it should contain either a timedelta or 
an integer number of (possibly fractional) seconds, depending on what color the 
bikeshed gets painted. This is, IIUC, precisely where Lennart is proposing to 
store the is_dst flag.

I just looked through the datetime documentation, and it looks like the 
currently blessed way of creating an aware datetime from a naive local datetime 
and a tzinfo is datetime.replace, which is too low level to handle the job. 
This method will either need to grow some validation, or there will need to be 
a tzinfo.localize(localtime, is_dst) method as well.

> If you store it in dt, why would you need the tzinfo? 

You can't do arithmetic without a time zone. Which is to say, if you try to do 
arithmetic without a time zone, you're implicitly doing it in a fixed offset 
time zone. So there's no way to disambiguate between
"2013-11-03 01:30:00-0500 America/Chicago" + "1 hour" = "2013-11-03 
01:30:00-0600 America/Chicago" and
"2013-11-03 01:30:00-0500 America/New_York" + "1 hour" = "2013-11-03 
02:30:00-0500 America/New_York".

> > 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.

I don't really mean we don't care; I mean that it's not close to orthogonal to 
the other things we care about in the way that local time and UTC time are. 
You'll never ask for *just* the DST flag. So making you look up in zoneinfo 
whether a given (localtime, offset, tzinfo) triple represents DST or STD is not 
as onerous, because if you used the other representation, you'd still be 
looking in zoneinfo for some other piece of information that the user asked for 
at the same time. So we implement the datetime.astimezone()
 
> > 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.

Sorry, I meant that to show off the internal representation, rather than 
intending it as the literal string representation. But I *do* think that the 
right representation of a time zone-aware time is (localtime, offset, tzinfo), 
and the __repr__ should reflect that. Anyone who wants "CDT" instead of "-0500 
America/Chicago" is talking to a human instead of a computer and should use 
strftime.

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

[Cristi Fati]

Sorry if i'm pushy
Would it worth me to send a patch with the changes? (i mean, would it bring
value to the product? were there requests for ctypes on WinIA64 ?)
If the answer to the above question is not "No", since the changes are in
libffi should i send patches to you or libffi guys? (i'm unfamiliar with
licensing terms).

Regards,
Cristi Fati.

On Wed, Apr 8, 2015 at 3:49 PM, Cristi Fati  wrote:

> 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 
> 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  wrote:
>> > On 8 April 2015 at 20:36, Maciej Fijalkowski  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

[Isaac Schwabacher]

On 15-04-09, Alexander Belopolsky  wrote:
> 
> On Thu, Apr 9, 2015 at 11:59 AM, Isaac Schwabacher 
>  wrote:
> 
> > I just looked through the datetime documentation, and it looks like the 
> > currently blessed way of creating an aware datetime from a naive local 
> > datetime and a tzinfo is datetime.replace, which is too low level to handle 
> > the job.
> 
> Not quite. That's how you would create a UTC datetime, but from there you can 
> get to your local timezone by calling astimezone() with no arguments:
> 
> >>> print(datetime.now(timezone.utc).astimezone())
> 2015-04-09 12:16:58.576272-04:00

All of the datetimes in this example are time zone aware; I meant if someone 
passed you datetime(2013, 11, 3, 1, 30) without a time zone. astimezone assumes 
that the input naive time is UTC, which is not the case here.

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

[Alexander Belopolsky]

On Thu, Apr 9, 2015 at 3:39 PM, Isaac Schwabacher 
wrote:

> > Well, you are right, but at least we do have a localtime utility hidden
> in the email package:
> >
> >
> > >>> from datetime import *
> > >>> from email.utils import localtime
> > >>> print(localtime(datetime.now()))
> > 2015-04-09 15:19:12.84-04:00
> >
> >
> > You can read  for the reasons it did
> not make into datetime.
>
> But that's restricted to the system time zone. Nothing good ever comes
> from the system time zone...


Let's solve one problem at a time.  You cannot have a complete TZ support
without supporting the local timezone.  The advantage of starting with the
local timezone is that most systems have a semi-standard interface to
obtain local zone name and offset for any UTC time.  To support multiple
zones, one would
need to bundle an external library which opens a lot of questions that are
orthogonal to the issue at hand:
how to deal with ambiguous local times in the presence of DST or other
political time shifts?

email.utils.localtime solves this problem in the same way as POSIX mktime
does: by introducing an optional isdst flag.  The main objection to this
interface was that in most use cases the programmer has no intelligent way
to set this flag to anything other than -1.

An alternative solution would be to have localtime(dt) (or astimezone(dt))
return a list of aware local times that in most cases will contain only one
element, but may contain 0 or 2 when dt falls on a switchover.
___
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

[Isaac Schwabacher]

On 15-04-09, Alexander Belopolsky  wrote:
> 
> On Thu, Apr 9, 2015 at 3:07 PM, Isaac Schwabacher 
>  wrote:
> 
> > > No, it does not. Please read the documentation: "self must be aware 
> > > (self.tzinfo must not be None, and self.utcoffset() must not return 
> > > None)."
> > 
> > Whoops, you're right. But that's even worse-- it doesn't give 
> > you a way to convert a naive datetime at all. Currently the only way from 
> > "2013-11-03 01:30:00" to "2013-11-03 01:30:00-0500 America/Chicago" is 
> > still datetime.replace().
> 
> 
> Well, you are right, but at least we do have a localtime utility hidden in 
> the email package:
> 
> 
> >>> from datetime import *
> >>> from email.utils import localtime
> >>> print(localtime(datetime.now()))
> 2015-04-09 15:19:12.84-04:00
> 
> 
> You can read  for the reasons it did not 
> make into datetime.

But that's restricted to the system time zone. Nothing good ever comes from the 
system time zone...

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

[Isaac Schwabacher]

On 15-04-09, Alexander Belopolsky  wrote:
> 
> On Thu, Apr 9, 2015 at 3:39 PM, Isaac Schwabacher 
>  wrote:
> 
> > > Well, you are right, but at least we do have a localtime utility hidden 
> > > in the email package:
> > >
> > > >>> from datetime import *
> > > >>> from email.utils import localtime
> > > >>> print(localtime(datetime.now()))
> > > 2015-04-09 15:19:12.84-04:00
> > >
> > > You can read  for the reasons it did 
> > > not make into datetime.
> > 
> > But that's restricted to the system time zone. Nothing good ever comes from 
> > the system time zone...
> 
> Let's solve one problem at a time. You cannot have a complete TZ support 
> without supporting the local timezone. The advantage of starting with the 
> local timezone is that most systems have a semi-standard interface to obtain 
> local zone name and offset for any UTC time. To support multiple zones, one 
> would
> need to bundle an external library which opens a lot of questions that are 
> orthogonal to the issue at hand:
> how to deal with ambiguous local times in the presence of DST or other 
> political time shifts?

PEP 431 proposes to import zoneinfo into the stdlib, so there will be a 
standard way to get this information. That's kind of the whole point. But 
there's really no good cross-platform way to get the name of the system time 
zone. tzlocal figures out what it is for certain classes of systems for which 
it's possible, and is also being proposed for stdlib inclusion in the PEP.

> email.utils.localtime solves this problem in the same way as POSIX mktime 
> does: by introducing an optional isdst flag. The main objection to this 
> interface was that in most use cases the programmer has no intelligent way to 
> set this flag to anything other than -1.
> 
> An alternative solution would be to have localtime(dt) (or astimezone(dt)) 
> return a list of aware local times that in most cases will contain only one 
> element, but may contain 0 or 2 when dt falls on a switchover.

This functionality should probably be exposed (in ruby it's 
TZInfo::TimeZone#periods_for_local, where TZInfo is an external package; I 
don't think it's easily available in pytz), but if it's the default way to do a 
conversion, I suspect that it's more likely to just lead to poor error 
reporting.

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

[Alexander Belopolsky]

On Thu, Apr 9, 2015 at 11:59 AM, Isaac Schwabacher 
wrote:

> I just looked through the datetime documentation, and it looks like the
> currently blessed way of creating an aware datetime from a naive local
> datetime and a tzinfo is datetime.replace, which is too low level to handle
> the job.


Not quite.  That's how you would create a UTC datetime, but from there you
can get to your local timezone by calling astimezone() with no arguments:

>>> print(datetime.now(timezone.utc).astimezone())
2015-04-09 12:16:58.576272-04:00
___
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

[Alexander Belopolsky]

On Thu, Apr 9, 2015 at 12:49 PM, Isaac Schwabacher 
wrote:
>
> if someone passed you datetime(2013, 11, 3, 1, 30) without a time zone.
astimezone assumes that the input naive time is UTC, which is not the case
here.


No, it does not.  Please read the documentation: "self must be aware
(self.tzinfo must not be None, and self.utcoffset() must not return None)."

<
https://docs.python.org/3/library/datetime.html#datetime.datetime.astimezone
>
___
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