Re: [Python-Dev] Draft PEP for time zone support.

[Lennart Regebro]

On Sun, Dec 30, 2012 at 11:19 AM, Steven D'Aprano wrote:

> If I've understood it correctly, that contradicts the PEP. One example
> given is "Etc/GMT+11", which is not a timezone *name*, but a timezone
> name *plus an offset*. Presumably if GMT+11 is legal, so should be
> GMT+10:30.
>

This depends on your definition of a timezone name. There is no generally
accepted authority for time zone names, the closest one we get is the
zoneinfo database itself, which is maintained by ICANN. It has an
Etc/GMT+11.

There is no "Etc/GMT+11" named here:
>
> http://en.wikipedia.org/wiki/**List_of_tz_database_time_zones
>

It exists in the database files, http://www.iana.org/time-zones, the
``etcetera`` file.


> nor is it included in /usr/share/zoneinfo/zone.tab in either of the systems
>

zone.tab contains none of the Etc/Something zones.


> I looked at (one Debian, one Centos), but there is Etc/GMT. So I conclude
> that the PEP allows timezone rules, not just names.
>

This is more problematic, and for that reason I'll change the PEP to use
another example.


> Either way, I think the PEP needs to clarify what counts as a valid name
> string.


A timezone file that exists in the zoneinfo database used.

Perhaps the database is out-of-date, or the government has suddenly declared
> a daylight savings change that isn't reflected yet in the database. Or you
> want to set your own TZ rules for testing. Or you've just declared
> independence
> from the central government and are setting up your own TZ rules.
>
> time.tzset supports rules as well as names. Is there some reason why this
> module should not do the same?
>

You will be able to make your own rules, the simplest is probably by adding
it to your zoneinfo database. Doing so is however not trivial, and outside
of the scope of this PEP.

//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/30/2012 05:19 AM, Steven D'Aprano wrote:
> There is no "Etc/GMT+11" named here:
> 
> http://en.wikipedia.org/wiki/List_of_tz_database_time_zones
> 
> nor is it included in /usr/share/zoneinfo/zone.tab in either of the
> systems I looked at (one Debian, one Centos), but there is Etc/GMT. So
> I conclude that the PEP allows timezone rules, not just names.

FWIW, my Ubuntu box has zone data for 'ETC/GMT+11':

 $ file /usr/share/zoneinfo/posix/Etc/GMT+11
 /usr/share/zoneinfo/posix/Etc/GMT+11: timezone data, version 2, \
  1 gmt time flag, 1 std time flag, no leap seconds, no transition times, \
  1 abbreviation char



Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlDgbjkACgkQ+gerLs4ltQ6w2QCgzqAFfOAigwVZMZEh+il+0grb
jsYAoMm1g8xnXe1dcgkFMEX0n14grDSH
=rCdb
-END PGP SIGNATURE-

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Steven D'Aprano]

On 29/12/12 15:40, Lennart Regebro wrote:

On Sat, Dec 29, 2012 at 2:23 AM, Steven D'Apranowrote:


The PEP says:

* New function :``timezone(name=None, db_path=None)``


   This function takes a name string that must be a string specifying a
   valid zoneinfo timezone, ie "US/Eastern", "Europe/Warsaw" or
"Etc/GMT+11".


It isn't 100% clear to me from the PEP what a valid name string would be,
but I assume that it will accept anything that the time.tzset function
will accept:



No, valid names are the names of time zones in the zoneinfo database.



If I've understood it correctly, that contradicts the PEP. One example
given is "Etc/GMT+11", which is not a timezone *name*, but a timezone
name *plus an offset*. Presumably if GMT+11 is legal, so should be
GMT+10:30.

There is no "Etc/GMT+11" named here:

http://en.wikipedia.org/wiki/List_of_tz_database_time_zones

nor is it included in /usr/share/zoneinfo/zone.tab in either of the systems
I looked at (one Debian, one Centos), but there is Etc/GMT. So I conclude
that the PEP allows timezone rules, not just names.

Either way, I think the PEP needs to clarify what counts as a valid name
string.




There
isn't really any usecase for defining up your own rules as that would mean
that you want a time zone that doesn't exist, which seems a bit pointless.
:-)


It means you want a time zone that doesn't exist in the database, which is
not the same as not existing in real life.

Perhaps the database is out-of-date, or the government has suddenly declared
a daylight savings change that isn't reflected yet in the database. Or you
want to set your own TZ rules for testing. Or you've just declared independence
from the central government and are setting up your own TZ rules.

time.tzset supports rules as well as names. Is there some reason why this
module should not do the same?

I also quote from /usr/share/doc/tzdata-2012f/README on my Centos system:

[quote]
README for the tz distribution
[...]

The 1989 update of the time zone package featured
[...]
*   reference data from the United States Naval Observatory for folks who
want to do additional time zones
[end quote]


So the people who prepare tzdata on Red Hat systems clearly think that there
are use-cases for making additional time zones.



--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Lennart Regebro]

On Sat, Dec 29, 2012 at 2:23 AM, Steven D'Aprano wrote:

> The PEP says:
>
> * New function :``timezone(name=None, db_path=None)``
>
>
>   This function takes a name string that must be a string specifying a
>   valid zoneinfo timezone, ie "US/Eastern", "Europe/Warsaw" or
> "Etc/GMT+11".
>
>
> It isn't 100% clear to me from the PEP what a valid name string would be,
> but I assume that it will accept anything that the time.tzset function
> will accept:
>

No, valid names are the names of time zones in the zoneinfo database. There
isn't really any usecase for defining up your own rules as that would mean
that you want a time zone that doesn't exist, which seems a bit pointless.
:-)

(We have KeyError rather than UnknownKeyError, NameError rather than
> UnknownNameError, etc.)
>

Sure, but what would otherwise a KeyError be unless an unkown or
non-existing key?

//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Steven D'Aprano]

On 29/12/12 05:02, Lennart Regebro wrote:

On Thu, Dec 20, 2012 at 5:43 PM, Barry Warsaw  wrote:



That would be `class UnknownTimeZoneError(ValueError, TimeZoneError)`.



As of today, in Pytz,  UnknownTimeZoneError in fact subclasses KeyError.
Any opinions against that?




The PEP says:

* New function :``timezone(name=None, db_path=None)``

  This function takes a name string that must be a string specifying a
  valid zoneinfo timezone, ie "US/Eastern", "Europe/Warsaw" or "Etc/GMT+11".


It isn't 100% clear to me from the PEP what a valid name string would be,
but I assume that it will accept anything that the time.tzset function
will accept:

http://docs.python.org/3/library/time.html#time.tzset


If so, then valid "name strings" may be either:

- strings which define the timezone rule explicitly, e.g:

  'AEST-10AEDT-11,M10.5.0,M3.5.0'


- or for convenience, rules already defined in your OS's timezone database:

  'Australia/Melbourne'


In either case, I don't think KeyError is the appropriate exception type.
I think that if I were to see a time zone string such as:

'Europe/Melbourne'  # no such place

'Eorupe/Stockhome'  # misspelled

'Etc/GMT+999'  # invalid offset

'AEST+10ASDT+11,M1050,M350'  # invalid starting and ending dates

'*&vbegs156s^g'  # utter rubbish

I would describe it as an *invalid* timezone, not a "missing" timezone.
So ValueError is a more appropriate base exception than KeyError.





There is no TimeZoneError today, and it would only be used for this
UnknownTimeZoneError, so I'm not sure it has much value.


In that case, can you rename UnknownTimeZoneError to TimeZoneError, which
is shorter and easier to read, write and remember?


(We have KeyError rather than UnknownKeyError, NameError rather than
UnknownNameError, etc.)



--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Terry Reedy]

On 12/28/2012 1:02 PM, Lennart Regebro wrote:

On Thu, Dec 20, 2012 at 5:43 PM, Barry Warsaw mailto:ba...@python.org>> wrote:


That would be `class UnknownTimeZoneError(ValueError, TimeZoneError)`.


As of today, in Pytz,  UnknownTimeZoneError in fact subclasses KeyError.
Any opinions against that?


Since the erroneous value is used as a key for a database lookup, and 
the error is probably detected by trying the lookup, I think that is ok. 
even if the user does not use []s.



There is no TimeZoneError today, and it would only be used for this
UnknownTimeZoneError, so I'm not sure it has much value.




--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Barry Warsaw]

On Dec 28, 2012, at 07:02 PM, Lennart Regebro wrote:

>On Thu, Dec 20, 2012 at 5:43 PM, Barry Warsaw  wrote:
>
>>
>> That would be `class UnknownTimeZoneError(ValueError, TimeZoneError)`.
>>
>
>As of today, in Pytz, UnknownTimeZoneError in fact subclasses KeyError.  Any
>opinions against that?  There is no TimeZoneError today, and it would only be
>used for this UnknownTimeZoneError, so I'm not sure it has much value.

Agreed.  If this is the only exception defined in the module, it sounds fine
to me.

Cheers,
-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Lennart Regebro]

On Thu, Dec 20, 2012 at 5:43 PM, Barry Warsaw  wrote:

>
> That would be `class UnknownTimeZoneError(ValueError, TimeZoneError)`.
>

As of today, in Pytz,  UnknownTimeZoneError in fact subclasses KeyError.
Any opinions against that?
There is no TimeZoneError today, and it would only be used for this
UnknownTimeZoneError, so I'm not sure it has much value.

//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Barry Warsaw]

On Dec 20, 2012, at 11:18 AM, Ben Finney wrote:

>Terry Reedy  writes:
>
>> On 12/12/2012 10:56 AM, Lennart Regebro wrote:
>>
>> >> It seems like calling get_timezone() with an unknown timezone
>> >> should just throw ValueError, not necessarily some custom
>> >> Exception?
>> >
>> > That could very well be. What are others opinions on this?
>>
>> ValueError. That is what it is. Nothing special here.
>
>I think it's useful to have this raise a custom exception
>UnknownTimeZoneError, subclassed from ValueError. That satisfies those
>(including me!) who think it should be a ValueError, while also making
>the exception more specific so it can be handled apart from other
>possible ValueError causes.
>
>In short: +1 to ‘class UnknownTimeZoneError(ValueError)’.

That would be `class UnknownTimeZoneError(ValueError, TimeZoneError)`.

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Ben Finney]

Terry Reedy  writes:

> On 12/12/2012 10:56 AM, Lennart Regebro wrote:
>
> >> It seems like calling get_timezone() with an unknown timezone
> >> should just throw ValueError, not necessarily some custom
> >> Exception?
> >
> > That could very well be. What are others opinions on this?
>
> ValueError. That is what it is. Nothing special here.

I think it's useful to have this raise a custom exception
UnknownTimeZoneError, subclassed from ValueError. That satisfies those
(including me!) who think it should be a ValueError, while also making
the exception more specific so it can be handled apart from other
possible ValueError causes.

In short: +1 to ‘class UnknownTimeZoneError(ValueError)’.

-- 
 \“Members of the general public commonly find copyright rules |
  `\implausible, and simply disbelieve them.” —Jessica Litman, |
_o__)  _Digital Copyright_ |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Barry Warsaw]

On Dec 14, 2012, at 12:01 PM, Christian Heimes wrote:

>* It's the release managers responsibility to make sure, all final
>  releases contain the current db. This needs to be added to the
>  RM's TODO list.

That would be PEP 101.

-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Christian Heimes]

Am 14.12.2012 09:31, schrieb Lennart Regebro:
> 1. Python will include a timezone database both in the source
> distribution and the Windows installer (although I suspect that binary
> packages for Linux distributions may skip this, but that's OK).

You need to specify the details. Where is the database stored and under
which condition is it updated?

Suggestions:

* The zoneinfo database is stored in the new package 'tzdata',
  that's Lib/tzdata in the source dist. The files are kept in
  our hg repository, too.

* A tool chain is provided that compiles the zoneinfos from a Olson
  tar.gz file. (Bonus points for a download + update script). The
  tool chain is included in source dist, e.g. Tools/.

* The db is updated on a regular basis during the development, alpha
  and beta phase by any core dev. Every patch level release shall
  contain the latest version of the db, maybe except for security
  releases.

* It's the release managers responsibility to make sure, all final
  releases contain the current db. This needs to be added to the
  RM's TODO list.


Who is going to create the tzdata_update package, how is it compiled and
how often should it be released?

One other thing, the zoneinfo database should be compatible with zipfile
distributions. The module should be able to load the files from a stdlib
zipfile. The feature is important for freeze, py2exe and py2app.

Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Lennart Regebro]

OK, so it's been 12 hours with no further discussion, so I'll make an
attempt to summarize what I think is the consensus changes before
updating the PEP.

1. Python will include a timezone database both in the source
distribution and the Windows installer (although I suspect that binary
packages for Linux distributions may skip this, but that's OK).

2. The timezone module becomes datetime.timezone, meaning datetime.py
is moved to datetime/__init__.py

3. get_timezone() will be just timezone() as no voices was raised to
defend get_timezone()

4. The db parameter in timezone() will be renamed db_path

5. is_dst will default to False

6. The UnknownTimeZoneError exception will be just a ValueError

7. The two errors raised when converting timezones will both inherit
from a base exception.

8. A better name for the timezone data package. "tzdata-override" was
suggested, I prefer "tzdata-update" as it is clearer.

//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Terry Reedy]

On 12/13/2012 4:07 AM, Lennart Regebro wrote:

On Thu, Dec 13, 2012 at 9:22 AM, Terry Reedy  wrote:

On 12/13/2012 1:06 AM, Lennart Regebro wrote:

All in all I would say I would prefer to install this per Python.


Then explicit update requires multiple downloads or copying. This is a
violation of DRY. If if is not too large, it would not hurt to never delete
it.


Yes, but this is no different that if you want to keep any library
updated over multiple Python versions.


How I do that for my multi-version packages is to put them in a separate 
'python' directory and put python.pth with the path to that directory in 
the various site-packages directories. Any change to the *one* copy is 
available to all versions and all will operate the same if the code is 
truly multi-version. When I installed 3.3, I copied python.pth into its 
site-packages and was ready to go.


> And I don't want to invent another installation procedure
> that works for just this,

An email or so ago, you said that the tz database should go in 
C:\programdata (which currently does not exist on my machine either). 
That would be a new, invented installation procedure.


> or have a  little script that checks periodically
> for updates only for this,

adding to the plethora of update checkers on windows already.


I *never* suggested this. In fact, I said that installing an updated 
database (available to all Python versions) with each release would be 
sufficient for nearly everyone on Windows.



either keep your Python and it's libraries updated or you do not, I
don't think this is any different,and I think it should have the
exact same mechanisms and functions as all other third-party PyPI
packages.


When I suggested that users be able to put the database where they want, 
*just like with any other third-party package PyPI package*, you are the 
one who said no, this should be special cased.


The situation is this: most *nixes have or can have one system tz 
database. Python code that uses it will give the same answer regardless 
of the Python version. Windows apparently does not have such a thing. So 
we can
a) not use the tz database in the stdlib because it would not work on 
Windows (the defacto current situation);

b) use it but let the functions fail on Windows;
c) install a different version of the database with each Python 
installation, that can only be used by that installation, so that 
results may depend on the Python version. (This seem to be what you are 
now proposing, and if bugfix releases update the data only for that 
version, could result in earlier versions giving more accurate answers.);
d) install one database at a time so all Python versions give the same 
answer, just as on *nix.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Christian Heimes]

Am 13.12.2012 10:07, schrieb Lennart Regebro:
> Yes, but this is no different that if you want to keep any library
> updated over multiple Python versions. And I don't want to invent
> another installation procedure that works for just this, or have a
> little script that checks periodically for updates only for this,
> adding to the plethora of update checkers on windows already. You
> either keep your Python and it's libraries updated or you do not, I
> don't think this is any different, and I think it should have the
> exact same mechanisms and functions as all other third-party PyPI
> packages.

+1

This PEP does fine without any auto-updatefeature. Please let Lennart
concentrate on the task at hand. If an auto-update system is still
wanted, it can and should be designed by somebody else as a separate
PEP. IMHO it's not Lennart's obligation to do so.

Christian

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Antoine Pitrou]

Le Thu, 13 Dec 2012 10:07:34 +0100,
Lennart Regebro  a écrit :
> On Thu, Dec 13, 2012 at 9:22 AM, Terry Reedy  wrote:
> > On 12/13/2012 1:06 AM, Lennart Regebro wrote:
> >> All in all I would say I would prefer to install this per Python.
> >
> > Then explicit update requires multiple downloads or copying. This
> > is a violation of DRY. If if is not too large, it would not hurt to
> > never delete it.
> 
> Yes, but this is no different that if you want to keep any library
> updated over multiple Python versions. And I don't want to invent
> another installation procedure that works for just this, or have a
> little script that checks periodically for updates only for this,
> adding to the plethora of update checkers on windows already. You
> either keep your Python and it's libraries updated or you do not, I
> don't think this is any different, and I think it should have the
> exact same mechanisms and functions as all other third-party PyPI
> packages.

Agreed. This doesn't warrant special-casing.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Lennart Regebro]

On Thu, Dec 13, 2012 at 9:22 AM, Terry Reedy  wrote:
> On 12/13/2012 1:06 AM, Lennart Regebro wrote:
>> All in all I would say I would prefer to install this per Python.
>
> Then explicit update requires multiple downloads or copying. This is a
> violation of DRY. If if is not too large, it would not hurt to never delete
> it.

Yes, but this is no different that if you want to keep any library
updated over multiple Python versions. And I don't want to invent
another installation procedure that works for just this, or have a
little script that checks periodically for updates only for this,
adding to the plethora of update checkers on windows already. You
either keep your Python and it's libraries updated or you do not, I
don't think this is any different, and I think it should have the
exact same mechanisms and functions as all other third-party PyPI
packages.

//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Glenn Linderman]

On 12/12/2012 11:32 PM, Janzert wrote:

On 12/13/2012 1:39 AM, Glenn Linderman wrote:

On 12/12/2012 6:10 PM, Janzert wrote:

On 12/12/2012 8:43 PM, Glenn Linderman wrote:

On 12/12/2012 5:36 PM, Brian Curtin wrote:


>> C:\ProgramData\Python



   ^ That.  Is not the path that the link below is talking
about, though.



It actually does; it is rather confusing though. :/


I agree with the below. But I have never seen a version of Windows on
which c:\ProgramData was the actual path for FOLDERID_ProgramData. Can
you reference documentation that states that it was there, for some
version?  This documentation speaks of:

c:\Documents and Settings\AllUsers\Application Data (which I knew from
XP, and I think 2000, not sure I remember NT)

In Vista.0, Vista.1, and Vista.2, I guess it is moved to
C:\users\AllUsers\AppData\Roaming (typically).

Neither of those would result in C:\ProgramData\Python.



The SO answer links to the KNOWNFOLDERID docs; the relevant entry 
specifically is at


http://msdn.microsoft.com/en-us/library/windows/desktop/dd378457.aspx#FOLDERID_ProgramData 



which gives the default path as,

%ALLUSERSPROFILE% (%ProgramData%, %SystemDrive%\ProgramData)

checking on my local windows 7 install gives:

C:\>echo %ALLUSERSPROFILE%
C:\ProgramData

C:\>echo %ProgramData%
C:\ProgramData


Interesting.  It _did_ say something about data that is not specific to 
a user... and yet I overlooked that.


Those environment variable settings are, indeed, on my Win 7 machine, so 
I have erred and apologize.


That said, the directory C:\ProgramData does NOT exist on my Win 7 
machine, so it appears that VERY LITTLE software actually uses that 
setting. (I have nearly a hundred free and commercial packages installed 
on this machine. Not that 100 is a large percentage of the available 
software for Windows, but if the use was common, 100 packages would be 
likely to contain one that used it, eh?).


Thanks for the education, especially because you had to beat it into my 
skull!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Terry Reedy]

On 12/13/2012 1:06 AM, Lennart Regebro wrote:

On Thu, Dec 13, 2012 at 2:24 AM, Terry Reedy  wrote:

Or ask the user where to put it.


If we ask where it should be installed, then we need a registry
setting for that


Right.


So I think that asking is not an option at all. It either goes in
%PROGRAMDATA%\Python\zoneinfo or it's not shared at all.


If that works for all xp+ versions, fine.




I know where I would choose, and it would
not be on my C drive. Un-installers would not delete (unless a reference
count were kept and were decremented to 0).


True, and that's annoying when those counters go wrong.


It seems to me that Windows has a mechanism for this, at least in some 
versions. But maybe it only works for dlls.



All in all I would say I would prefer to install this per Python.


Then explicit update requires multiple downloads or copying. This is a 
violation of DRY. If if is not too large, it would not hurt to never 
delete it.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Janzert]

On 12/13/2012 1:39 AM, Glenn Linderman wrote:

On 12/12/2012 6:10 PM, Janzert wrote:

On 12/12/2012 8:43 PM, Glenn Linderman wrote:

On 12/12/2012 5:36 PM, Brian Curtin wrote:


>> C:\ProgramData\Python



   ^ That.  Is not the path that the link below is talking
about, though.



It actually does; it is rather confusing though. :/


I agree with the below. But I have never seen a version of Windows on
which c:\ProgramData was the actual path for FOLDERID_ProgramData. Can
you reference documentation that states that it was there, for some
version?  This documentation speaks of:

c:\Documents and Settings\AllUsers\Application Data (which I knew from
XP, and I think 2000, not sure I remember NT)

In Vista.0, Vista.1, and Vista.2, I guess it is moved to
C:\users\AllUsers\AppData\Roaming (typically).

Neither of those would result in C:\ProgramData\Python.



The SO answer links to the KNOWNFOLDERID docs; the relevant entry 
specifically is at


http://msdn.microsoft.com/en-us/library/windows/desktop/dd378457.aspx#FOLDERID_ProgramData

which gives the default path as,

%ALLUSERSPROFILE% (%ProgramData%, %SystemDrive%\ProgramData)

checking on my local windows 7 install gives:

C:\>echo %ALLUSERSPROFILE%
C:\ProgramData

C:\>echo %ProgramData%
C:\ProgramData



It's referring to KNOWNFOLDERID constant FOLDERID_ProgramData. The
actual on disk location for this has changed over windows versions. As
noted below in the SO link given:

"Note that this documentation refers to the typical path as per older
versions of Windows. In modern versions of Windows it is located in
%SystemDrive%\ProgramData."


>
>
> Making a new top-level directory without asking is obnoxious.

See
http://stackoverflow.com/questions/9518890/what-is-the-significance-programdata-in-windows








___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Glenn Linderman]

On 12/12/2012 6:10 PM, Janzert wrote:

On 12/12/2012 8:43 PM, Glenn Linderman wrote:

On 12/12/2012 5:36 PM, Brian Curtin wrote:


>> C:\ProgramData\Python



   ^ That.  Is not the path that the link below is talking
about, though.



It actually does; it is rather confusing though. :/ 


I agree with the below. But I have never seen a version of Windows on 
which c:\ProgramData was the actual path for FOLDERID_ProgramData. Can 
you reference documentation that states that it was there, for some 
version?  This documentation speaks of:


c:\Documents and Settings\AllUsers\Application Data (which I knew from 
XP, and I think 2000, not sure I remember NT)


In Vista.0, Vista.1, and Vista.2, I guess it is moved to 
C:\users\AllUsers\AppData\Roaming (typically).


Neither of those would result in C:\ProgramData\Python.

It's referring to KNOWNFOLDERID constant FOLDERID_ProgramData. The 
actual on disk location for this has changed over windows versions. As 
noted below in the SO link given:


"Note that this documentation refers to the typical path as per older 
versions of Windows. In modern versions of Windows it is located in 
%SystemDrive%\ProgramData."



>
>
> Making a new top-level directory without asking is obnoxious.

See
http://stackoverflow.com/questions/9518890/what-is-the-significance-programdata-in-windows 



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Lennart Regebro]

On Thu, Dec 13, 2012 at 2:24 AM, Terry Reedy  wrote:
> Or ask the user where to put it.

If we ask where it should be installed, then we need a registry
setting for that or we don't know where it's located when it is to be
used. And if we ask, then people will install it in non-standard
locations. While installers for software with Python don't want their
users to be asked, so they'll install it in the standard location,
overriding the managers preferred, updated custom location with the
standard location with a database that is probably not updated.

So I think that asking is not an option at all. It either goes in
%PROGRAMDATA%\Python\zoneinfo or it's not shared at all.

> I know where I would choose, and it would
> not be on my C drive. Un-installers would not delete (unless a reference
> count were kept and were decremented to 0).

True, and that's annoying when those counters go wrong.

All in all I would say I would prefer to install this per Python.

//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Brian Curtin]

On Wed, Dec 12, 2012 at 8:10 PM, Janzert  wrote:
> On 12/12/2012 8:43 PM, Glenn Linderman wrote:
>>
>> On 12/12/2012 5:36 PM, Brian Curtin wrote:
>>>
>>>
>>> >> C:\ProgramData\Python
>>>
>>
>>^ That.  Is not the path that the link below is talking
>> about, though.
>>
>
> It actually does; it is rather confusing though. :/ It's referring to
> KNOWNFOLDERID constant FOLDERID_ProgramData. The actual on disk location for
> this has changed over windows versions. As noted below in the SO link given:
>
> "Note that this documentation refers to the typical path as per older
> versions of Windows. In modern versions of Windows it is located in
> %SystemDrive%\ProgramData."

Correct.

Anyway, on with the actual timezone stuff...
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Janzert]

On 12/12/2012 8:43 PM, Glenn Linderman wrote:

On 12/12/2012 5:36 PM, Brian Curtin wrote:


>> C:\ProgramData\Python



   ^ That.  Is not the path that the link below is talking
about, though.



It actually does; it is rather confusing though. :/ It's referring to 
KNOWNFOLDERID constant FOLDERID_ProgramData. The actual on disk location 
for this has changed over windows versions. As noted below in the SO 
link given:


"Note that this documentation refers to the typical path as per older 
versions of Windows. In modern versions of Windows it is located in 
%SystemDrive%\ProgramData."



>
>
> Making a new top-level directory without asking is obnoxious.

See
http://stackoverflow.com/questions/9518890/what-is-the-significance-programdata-in-windows








___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Glenn Linderman]

On 12/12/2012 5:36 PM, Brian Curtin wrote:


>> C:\ProgramData\Python



  ^ That.  Is not the path that the link below is talking 
about, though.



>
>
> Making a new top-level directory without asking is obnoxious.

See 
http://stackoverflow.com/questions/9518890/what-is-the-significance-programdata-in-windows




___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Brian Curtin]

On Dec 12, 2012 7:24 PM, "Terry Reedy"  wrote:
>
> On 12/12/2012 7:27 PM, Brian Curtin wrote:
>>
>> On Wed, Dec 12, 2012 at 6:10 PM, MRAB  wrote:
>>>
>>> On 2012-12-12 23:33, Lennart Regebro wrote:


 On Thu, Dec 13, 2012 at 12:23 AM, Terry Reedy  wrote:
>
>
> As a Windows user, I would like there to be one tz data file used by
all
> Python versions on my machine, including ones included with other
apps.



 That would be nice, but where would that be installed? There is no
 standard location for zoneinfo files. And do we really want to install
 python-specific files outside the Python tree?
>
>
> There is no 'Python tree' on windows. Rather, there is a separate tree
for each version, located where the user directs.
>
> Windows used to have a %APPDATA% directory variable. Not sure about Win
7, let alone 8. Martin and others should know better.
>
> Or ask the user where to put it. I know where I would choose, and it
would not be on my C drive. Un-installers would not delete (unless a
reference count were kept and were decremented to 0).
>
>
>>> Python version x.y is installed into, say, C:\Pythonxy, so perhaps a
>>> good place would be, say, C:\Python.
>>
>>
>> C:\ProgramData\Python
>
>
> Making a new top-level directory without asking is obnoxious.

See
http://stackoverflow.com/questions/9518890/what-is-the-significance-programdata-in-windows
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Terry Reedy]

On 12/12/2012 7:27 PM, Brian Curtin wrote:

On Wed, Dec 12, 2012 at 6:10 PM, MRAB  wrote:

On 2012-12-12 23:33, Lennart Regebro wrote:


On Thu, Dec 13, 2012 at 12:23 AM, Terry Reedy  wrote:


As a Windows user, I would like there to be one tz data file used by all
Python versions on my machine, including ones included with other apps.



That would be nice, but where would that be installed? There is no
standard location for zoneinfo files. And do we really want to install
python-specific files outside the Python tree?


There is no 'Python tree' on windows. Rather, there is a separate tree 
for each version, located where the user directs.


Windows used to have a %APPDATA% directory variable. Not sure about Win 
7, let alone 8. Martin and others should know better.


Or ask the user where to put it. I know where I would choose, and it 
would not be on my C drive. Un-installers would not delete (unless a 
reference count were kept and were decremented to 0).



Python version x.y is installed into, say, C:\Pythonxy, so perhaps a
good place would be, say, C:\Python.


C:\ProgramData\Python


Making a new top-level directory without asking is obnoxious.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Brian Curtin]

On Wed, Dec 12, 2012 at 6:10 PM, MRAB  wrote:
> On 2012-12-12 23:33, Lennart Regebro wrote:
>>
>> On Thu, Dec 13, 2012 at 12:23 AM, Terry Reedy  wrote:
>>>
>>> As a Windows user, I would like there to be one tz data file used by all
>>> Python versions on my machine, including ones included with other apps.
>>
>>
>> That would be nice, but where would that be installed? There is no
>> standard location for zoneinfo files. And do we really want to install
>> python-specific files outside the Python tree?
>>
> Python version x.y is installed into, say, C:\Pythonxy, so perhaps a
> good place would be, say, C:\Python.

C:\ProgramData\Python
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[MRAB]

On 2012-12-12 23:33, Lennart Regebro wrote:

On Thu, Dec 13, 2012 at 12:23 AM, Terry Reedy  wrote:

As a Windows user, I would like there to be one tz data file used by all
Python versions on my machine, including ones included with other apps.


That would be nice, but where would that be installed? There is no
standard location for zoneinfo files. And do we really want to install
python-specific files outside the Python tree?


Python version x.y is installed into, say, C:\Pythonxy, so perhaps a
good place would be, say, C:\Python.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Lennart Regebro]

On Thu, Dec 13, 2012 at 12:23 AM, Terry Reedy  wrote:
> As a Windows user, I would like there to be one tz data file used by all
> Python versions on my machine, including ones included with other apps.

That would be nice, but where would that be installed? There is no
standard location for zoneinfo files. And do we really want to install
python-specific files outside the Python tree?


//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Terry Reedy]

On 12/12/2012 10:56 AM, Lennart Regebro wrote:


It seems like calling get_timezone() with an unknown timezone should
just throw ValueError, not necessarily some custom Exception?


That could very well be. What are others opinions on this?


ValueError. That is what it is. Nothing special here.


Why not keep a bit more of the pytz API to make porting easy?


The renaming of the timezone() function to get_timezone() is indeed small,


And gratuitous, to me. I don't generally like 'get' prefixes anyway.


but changing pytz.timezone(foo) to timezone.timezone(foo) is really
significantly easier than renaming it to timezone.get_timezone(foo).

If we keep all of the API intact you could do

 try:
 import pytz as timezone
 except ImportError:
 import timezone

Which would make porting quicker, that's true, but do we really want to keep
unecessary API's around forever? Isn't it better to minimize the noise from
the start?


While the module that was the basis for the ipaddress module was 
released on PyPI and its api developed however it did, the API was 
worked over quite a bit before the addition of ipaddress. So I agree 
that the current api can be revised before being more-or-less frozen in 
the stdlib.



It also seems relatively painless to keep localize() and normalize()
functions around for easy porting.


Sure, but you then have two ways of doing the same thing, which I think we
should avoid.


I agree that this is precisely the time to remove cruft (if indeed it is 
such).


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Terry Reedy]

On 12/12/2012 11:53 AM, Guido van Rossum wrote:


Bingo. As long as the recipe to update is clear, most users can ignore
this, because the countries about which they care don't change DST
rules often enough for it to matter. When it does matter, they'll know
(changing the DST rules is something that local news sources tend to
track :-) and they can update their software when stuff they use
starts getting the time wrong. Obviously sysadmins responsible for
large numbers of users can make this into a routine, and ditto people
who run services. But these folks are professionals and are good at
automating tasks like this.


As a Windows user, I would like there to be one tz data file used by all 
Python versions on my machine, including ones included with other apps. 
I would like every installer, including for bug fix releases, to update 
it. This should be sufficient for 99% of Windows users. As Guido says 
above, the docs should tell the other 1% how to update it explicitly.



--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Christian Tismer]

On 12.12.12 02:43, Guido van Rossum wrote:

On Tue, Dec 11, 2012 at 5:11 PM, Robert Brewer  wrote:

Guido van Rossum wrote:

Sent: Tuesday, December 11, 2012 4:11 PM
To: Antoine Pitrou
Cc:python-dev@python.org
Subject: Re: [Python-Dev] Draft PEP for time zone support.

On Tue, Dec 11, 2012 at 8:07 AM, Antoine Pitrou
wrote:

Le Tue, 11 Dec 2012 16:23:37 +0100,
Lennart Regebro  a écrit :

Changes in the ``datetime``-module
--

A new ``is_dst`` parameter is added to several of the `tzinfo`
methods to handle time ambiguity during DST changeovers.

* ``tzinfo.utcoffset(self, dt, is_dst=True)``

* ``tzinfo.dst(self, dt, is_dst=True)``

* ``tzinfo.tzname(self, dt, is_dst=True)``

The ``is_dst`` parameter can be ``True`` (default), ``False``, or
``None``.

``True`` will specify that the given datetime should be interpreted
as happening during daylight savings time, ie that the time

specified

is before the change from DST.

Why is it True by default? Do we have statistics showing that Python
gets more use in summer?

My question exactly.

"Summer" in the USA, at least, is 238 days in 2012, while "Winter" into 2013 is 
only 126 days:


import datetime
datetime.date(2012, 11, 4) - datetime.date(2012, 3, 11)

datetime.timedelta(238)

datetime.date(2013, 3, 10) - datetime.date(2012, 11, 4)

datetime.timedelta(126)

Very funny, but that can't be the real reason. *Most* datetime values
aren't ambiguous, so in those cases the parameter should be ignored,
right? There's only one hour per year where you need to specify it
(two, if we want to artificially assign a meaning to values falling
the impossible hour). And during those times it's equally likely that
you meant either of the possibilities. I think the meaning of the
parameter must be clarified, perhaps as follows:

- ignored except during the ambiguous hour and during the impossible hour
- during the ambiguous or impossible hour:
   - if True, prefer/pretend DST
   - if False, prefer/pretend non-DST
   - if None, raise an error

Here I'd prefer the default to be None if I had to do it over again,
but given that the current behavior is one of the first two (which
one?) we probably can't do that. Still, it's slightly confusing that
passing None is not the same as omitting the parameter altogether --
there aren't many APIs that explicitly support passing None but don't
use it as the default (though there probably are some precedents).
Maybe requesting an error should be done through some other special
value, and None should be the same as omitted and the same as the old
behavior? But where would the special value come from? It should be
made as easy as possible to "do the right thing" (i.e. raise an
error). Or maybe have a separate Boolean flag to request an error?



I see an issue here that makes me a little uncomfortable:
Having a default that makes code work all year but raises an error during
the "impossible hour" could be problematic in critical code.
Can we make this more explicit by forcing the users to decide?

I like the idea of the extra boolean flag here, because it will be 
explicitly

visible that this code intentionally creates an exception.
Or even not a flag, but the exception to be raised, or a callable to
handle this case?

Sloppy coding can be dangerous. So maybe the warning module could be
helpful as well: If None is passed and no explicit flag/exception/callable
given, bother the user with a warning message ;-)

cheers - chris

--
Christian Tismer :^)<mailto:tis...@stackless.com>
Software Consulting  : Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121 :*Starship*http://starship.python.net/
14482 Potsdam: PGP key ->http://pgp.uni-mainz.de
phone +49 173 24 18 776  fax +49 (30) 700143-0023
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?http://www.stackless.com/

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Lennart Regebro]

On Wed, Dec 12, 2012 at 5:54 PM, Steve Dower  wrote:
> Details of the registry entries are at 
> http://msdn.microsoft.com/en-us/library/ms725481.aspx. It looks like the data 
> is focused on modern timezones rather than localities, which would mean a 
> many-to-one mapping from zoneinfo. Unfortunately it doesn't look like there's 
> enough overlap to allow an automated mapping.

No, but the Unicode consortium (I think) is keeping a mapping updated
manually. I'm using that in tzlocal, to figure out the local timezone
of the computer on Windows.
However, I think that mixing and matching timezone data in this way
from the two systems are likely to be full of pitfalls edge-cases and
complexities I do not dare even think seriously about. There will
probably be *less* errors by just keeping an old timezone database
around. Besides, what it they don't run Windows update? Then the data
still is outdated?

//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Lennart Regebro]

On Wed, Dec 12, 2012 at 5:21 PM, Dirkjan Ochtman  wrote:
> That entirely depends on when you define to be "the start". It seems
> to me the consensus on python-dev has been that packages primarily
> evolve outside the stdlib; it seems a bit weird to then, at the time
> of stdlib inclusion, start changing the API.

But this bit of the API is there only as a hack, because stdlib does
not support is_dst. We are changing that. Hence those extra functions
are no longer needed.

//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Greg Ewing]

On Tue, Dec 11, 2012 at 8:07 AM, Antoine Pitrou  wrote:


Do we have statistics showing that Python
gets more use in summer?


Well, pythons are cold-blooded, so they're probably more
active during the warmer seasons...

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Éric Araujo]

Hi,

Le 12/12/2012 04:53, Christian Heimes a écrit :
> Am 12.12.2012 01:58, schrieb Nick Coghlan:
>> Ick, why a new module? Why not just add this directly to datetime? (It
>> doesn't need to be provided by the C accelerator, it can go straight in
>> the pure Python part).
> 
> +1 for something like datetime.timezone
> 
> How well does hg handle files renames? The datetime module could be
> converted to a package.

Quite well.  It’s easy to rename datetime.py to datetime/__init__py, and
subsequent fixes in 3.3’s datetime.py will be merged into
datetime/__init__.py by Mercurial’s merge subsystem.

Cheers
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Steve Dower]

Paul Moore wrote:
> On 12 December 2012 16:11, Brian Curtin  wrote:
> > I don't think it's all that bad to include a small script on Windows
> > which runs every few days to check PyPI, then present an option to
> > update the info. This is what Java itself is doing anyway.
> 
> What would that do in an environment without internet access? Or with a
> firewall blocking Python's requests and returning an error page without
> warning (so the updater just sees incorrect data)? What about corporate
> environments that want to control the rollout of updates? (I can't imagine
> that in practice, but certainly companies do it for Java). Most Windows
> updaters use the "official" Windows APIs so that they work properly with
> odd cases like ISA proxies taking credentials from the Windows user login.
> Python's stdlib doesn't support that type of thing.
> 
> I'm -1 on auto-updating because it's too easy to produce a "nearly right"
> solution that doesn't work in highly-controlled (e.g.,
> corporate) environments. And a "correct" solution would be hard to support
> with python-dev's level of Windows expertise.

And what about embedded installations of Python, such as in TortoiseHg? And all 
the people (such as myself) who disable updaters that they don't like or didn't 
expect?

The "correct" solution on Windows may be to use a static database for 
historical dates and the information in the registry for current and future 
dates. The registry is updated through Windows Update, which is at least as 
reliable as anything Python could do. (I'm not sure exactly what the state of 
updates to older versions is like, but I'd assume WinXP still gets timezone 
updates and Win2K doesn't.)

Details of the registry entries are at 
http://msdn.microsoft.com/en-us/library/ms725481.aspx. It looks like the data 
is focused on modern timezones rather than localities, which would mean a 
many-to-one mapping from zoneinfo. Unfortunately it doesn't look like there's 
enough overlap to allow an automated mapping.

That said, it is incredibly easy to convert between UTC and local 
(http://msdn.microsoft.com/en-us/library/ms724949.aspx), even for dates in the 
past or future when the information is available. It's just that timezones 
other than the user's preference are difficult.

Cheers,
Steve
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Guido van Rossum]

On Wed, Dec 12, 2012 at 8:44 AM, Antoine Pitrou  wrote:
> Le Wed, 12 Dec 2012 10:11:15 -0600,
> Brian Curtin  a écrit :
>>
>> I don't think it's all that bad to include a small script on Windows
>> which runs every few days to check PyPI, then present an option to
>> update the info. This is what Java itself is doing anyway.
>
> I don't get why people are so obsessed about updating the timezone
> database. Really, this is not worse than having a vulnerable OpenSSL
> linked with your Python executable. Purity does not bring any
> advantage here.

Bingo. As long as the recipe to update is clear, most users can ignore
this, because the countries about which they care don't change DST
rules often enough for it to matter. When it does matter, they'll know
(changing the DST rules is something that local news sources tend to
track :-) and they can update their software when stuff they use
starts getting the time wrong. Obviously sysadmins responsible for
large numbers of users can make this into a routine, and ditto people
who run services. But these folks are professionals and are good at
automating tasks like this.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Antoine Pitrou]

Le Wed, 12 Dec 2012 10:11:15 -0600,
Brian Curtin  a écrit :
> 
> I don't think it's all that bad to include a small script on Windows
> which runs every few days to check PyPI, then present an option to
> update the info. This is what Java itself is doing anyway.

I don't get why people are so obsessed about updating the timezone
database. Really, this is not worse than having a vulnerable OpenSSL
linked with your Python executable. Purity does not bring any
advantage here.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Paul Moore]

On 12 December 2012 16:11, Brian Curtin  wrote:
> I don't think it's all that bad to include a small script on Windows
> which runs every few days to check PyPI, then present an option to
> update the info. This is what Java itself is doing anyway.

What would that do in an environment without internet access? Or with
a firewall blocking Python's requests and returning an error page
without warning (so the updater just sees incorrect data)? What about
corporate environments that want to control the rollout of updates? (I
can't imagine that in practice, but certainly companies do it for
Java). Most Windows updaters use the "official" Windows APIs so that
they work properly with odd cases like ISA proxies taking credentials
from the Windows user login. Python's stdlib doesn't support that type
of thing.

I'm -1 on auto-updating because it's too easy to produce a "nearly
right" solution that doesn't work in highly-controlled (e.g.,
corporate) environments. And a "correct" solution would be hard to
support with python-dev's level of Windows expertise.

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Dirkjan Ochtman]

On Wed, Dec 12, 2012 at 4:56 PM, Lennart Regebro  wrote:
>> Why not keep a bit more of the pytz API to make porting easy?
>
> The renaming of the timezone() function to get_timezone() is indeed small,
> but changing pytz.timezone(foo) to timezone.timezone(foo) is really
> significantly easier than renaming it to timezone.get_timezone(foo).
>
> If we keep all of the API intact you could do
>
> try:
> import pytz as timezone
> except ImportError:
> import timezone
>
> Which would make porting quicker, that's true, but do we really want to keep
> unecessary API's around forever? Isn't it better to minimize the noise from
> the start?

That entirely depends on when you define to be "the start". It seems
to me the consensus on python-dev has been that packages primarily
evolve outside the stdlib; it seems a bit weird to then, at the time
of stdlib inclusion, start changing the API.

>> Why is it True by default? Do we have statistics showing that Python
>> gets more use in summer?
>
> Because for some reason both me and Stuart Bishop thought it should be, but
> at least in my case I don't have any actual good reason why. Checking with
> how pytz does this shows that pytz in fact defaults to False, so I think
> the default should be False.

Here, too, I think that sticking with pytz's default would be a good idea.

Cheers,

Dirkjan
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Brian Curtin]

On Wed, Dec 12, 2012 at 9:56 AM, Lennart Regebro  wrote:
> General comments:
>
>
> It seems like the consensus is moving towards making sure there always is a
> database available. If this means including it in the standard Python
> distribution as well, or only on Windows, I don't know, opinions on that are
> welcome.
>
> The steps to look for a database would then change to:
>
>   1. The path specified, if not None.
>
>   2. The module for timezone "overrides".
>
>   3. The OS database.
>
>   4. The database included in Python.
>
> We need to determine if a warning should be raised in case of 4 or not, as
> well as the name for the override module. I think the word "override" here is
> possibly unclear, I'd prefer something like "timezone-update" or similar.
>
> I'm personally a bit sceptical to writing a special updater/installer just
> for this. I don't want to have a special unique way to install this package.
>
> As it comes to OS packages, Christian Heimes pointed out that most Windows
> installations today has Java installed, and kept updated, and it has a
> zoneinfo database. We could consider using that on Windows as well, although
> it admittedly feels quite icky.

Depending on Java being installed or even installing it alongside
Python would be a funny April Fools prank. This can't happen.

I don't think it's all that bad to include a small script on Windows
which runs every few days to check PyPI, then present an option to
update the info. This is what Java itself is doing anyway.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Lennart Regebro]

General comments:


It seems like the consensus is moving towards making sure there always is a
database available. If this means including it in the standard Python
distribution as well, or only on Windows, I don't know, opinions on that are
welcome.

The steps to look for a database would then change to:

  1. The path specified, if not None.

  2. The module for timezone "overrides".

  3. The OS database.

  4. The database included in Python.

We need to determine if a warning should be raised in case of 4 or not, as
well as the name for the override module. I think the word "override" here is
possibly unclear, I'd prefer something like "timezone-update" or similar.

I'm personally a bit sceptical to writing a special updater/installer just
for this. I don't want to have a special unique way to install this package.

As it comes to OS packages, Christian Heimes pointed out that most Windows
installations today has Java installed, and kept updated, and it has a
zoneinfo database. We could consider using that on Windows as well, although
it admittedly feels quite icky.

I haven't been able to find any other common locations for the
zoneinfo database on Windows.



Specific answers:

On Tue, Dec 11, 2012 at 4:39 PM, Dirkjan Ochtman  wrote:

> I wonder if there needs to be something here about how to port from
> pytz to the new timezone library.

It would be nice to have, but I don't think it's necessary to have in the PEP.

> It seems like calling get_timezone() with an unknown timezone should
> just throw ValueError, not necessarily some custom Exception?

That could very well be. What are others opinions on this?

> Why not keep a bit more of the pytz API to make porting easy?

The renaming of the timezone() function to get_timezone() is indeed small,
but changing pytz.timezone(foo) to timezone.timezone(foo) is really
significantly easier than renaming it to timezone.get_timezone(foo).

If we keep all of the API intact you could do

try:
import pytz as timezone
except ImportError:
import timezone

Which would make porting quicker, that's true, but do we really want to keep
unecessary API's around forever? Isn't it better to minimize the noise from
the start?

> It also seems relatively painless to keep localize() and normalize()
> functions around for easy porting.

Sure, but you then have two ways of doing the same thing, which I think we
should avoid.


On Tue, Dec 11, 2012 at 5:07 PM, Antoine Pitrou  wrote:

>> The ``is_dst`` parameter can be ``True`` (default), ``False``, or
>> ``None``.
>>
> Why is it True by default? Do we have statistics showing that Python
> gets more use in summer?

Because for some reason both me and Stuart Bishop thought it should be, but
at least in my case I don't have any actual good reason why. Checking with
how pytz does this shows that pytz in fact defaults to False, so I think
the default should be False.


On Wed, Dec 12, 2012 at 3:50 AM, Barry Warsaw  wrote:

>> This is likely the hardest part of this PEP as this involves updating the

> Oops, something got cut off there.

Ah, yes, I was going to write that the difficult bit was updating the
_datetime.c module.

> Why add a new module instead of putting all this into the existing datetime
> module, either directly or as a submodule? Seems like the obvious place to
> put it instead of claiming another top-level module name.

pytz as it is consists of several modules, and a significant amount of code,
it didn't feel right to move all that into the datetime.py module. It also
didn't feel right to then not implement it in _datetime.c, but perhaps that's
just me being silly.

But a submodule could work.

> I'm bikeshedding, but can we find a better name than `db` for the second
> argument?  Something that makes it obvious we're looking for file system path?

Absolutely. db_path?

> I'd really like to see a TimeZoneError base class from which all these new
> exceptions inherit.

That makes sense.

>>The ``timezonedata``-package
>>-
>
> Just to be clear, this doesn't expose any new modules, right?

That's the intention, yes, although I haven't investigated ways of knowing if
it's installed or not yet, and exposing a module is the obvious way of doing
that. But I'm hoping there will be better ways, right?

> One other thing that the PEP should describe is what happens on a distro that
> has timezone data, but which you also pip install the PyPI tzdata package.
> Which one wins?  Is there a way to control it, other than providing an
> explicit path?  Is there a way to uninstall the PyPI package?  Does the API
> need to provide a method which tells you where the database it is using by
> default lives?

The PyPI package wins, I'll clarify that bit. I'm think the data should end
up in site-packages somewhere, and that it should be installable and
uninstallable with pip/easy_install and by simply deleting it.


On Wed, Dec 12, 2012 at 4:14 AM, Nick Coghlan  wrote:

> That's a 

Re: [Python-Dev] Draft PEP for time zone support.

[Christian Heimes]

Am 12.12.2012 01:58, schrieb Nick Coghlan:
> Ick, why a new module? Why not just add this directly to datetime? (It
> doesn't need to be provided by the C accelerator, it can go straight in
> the pure Python part).

+1 for something like datetime.timezone

How well does hg handle files renames? The datetime module could be
converted to a package.

> I'd prefer a more aggressive name for this like "tzdata_override". My
> rationale is that *nix users need to thoroughly aware that if they
> install this package, they will stop benefiting from the automatic tz
> database updates provided by their OS (especially if they install it
> into the system site packages on a distro that has migrated to Python 3
> for system tools).

+1, too.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Paul Moore]

On 12 December 2012 00:58, Nick Coghlan  wrote:
> I'd prefer a more aggressive name for this like "tzdata_override". My
> rationale is that *nix users need to thoroughly aware that if they install
> this package, they will stop benefiting from the automatic tz database
> updates provided by their OS (especially if they install it into the system
> site packages on a distro that has migrated to Python 3 for system tools).
>
> Such a name would also make it possible to provide *two* packaged databases,
> one checked before the OS data (tzdata_override), and one shipped with
> Python itself that is used only if the OS doesn't provide the timezone
> database (tzdata_fallback). tzdata_fallback would then be updated to the
> latest Olsen database for each maintenance release. Cross-platform
> applications that wanted more reliably up to date timezone data could then
> conditionally depend on tzdata_override for Windows deployments (using the
> environment marker support in metadata 1.2+).

That sounds sensible, EIBTI and all that. It is a lot simpler than
shipping the package and some sort of auto-updater, too.

Paul
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Guido van Rossum]

On Tue, Dec 11, 2012 at 5:11 PM, Robert Brewer  wrote:
> Guido van Rossum wrote:
>> Sent: Tuesday, December 11, 2012 4:11 PM
>> To: Antoine Pitrou
>> Cc: python-dev@python.org
>> Subject: Re: [Python-Dev] Draft PEP for time zone support.
>>
>> On Tue, Dec 11, 2012 at 8:07 AM, Antoine Pitrou 
>> wrote:
>> > Le Tue, 11 Dec 2012 16:23:37 +0100,
>> > Lennart Regebro  a écrit :
>> >>
>> >> Changes in the ``datetime``-module
>> >> --
>> >>
>> >> A new ``is_dst`` parameter is added to several of the `tzinfo`
>> >> methods to handle time ambiguity during DST changeovers.
>> >>
>> >> * ``tzinfo.utcoffset(self, dt, is_dst=True)``
>> >>
>> >> * ``tzinfo.dst(self, dt, is_dst=True)``
>> >>
>> >> * ``tzinfo.tzname(self, dt, is_dst=True)``
>> >>
>> >> The ``is_dst`` parameter can be ``True`` (default), ``False``, or
>> >> ``None``.
>> >>
>> >> ``True`` will specify that the given datetime should be interpreted
>> >> as happening during daylight savings time, ie that the time
>> specified
>> >> is before the change from DST.
>> >
>> > Why is it True by default? Do we have statistics showing that Python
>> > gets more use in summer?
>>
>> My question exactly.
>
> "Summer" in the USA, at least, is 238 days in 2012, while "Winter" into 2013 
> is only 126 days:
>
>>>> import datetime
>>>> datetime.date(2012, 11, 4) - datetime.date(2012, 3, 11)
> datetime.timedelta(238)
>>>> datetime.date(2013, 3, 10) - datetime.date(2012, 11, 4)
> datetime.timedelta(126)

Very funny, but that can't be the real reason. *Most* datetime values
aren't ambiguous, so in those cases the parameter should be ignored,
right? There's only one hour per year where you need to specify it
(two, if we want to artificially assign a meaning to values falling
the impossible hour). And during those times it's equally likely that
you meant either of the possibilities. I think the meaning of the
parameter must be clarified, perhaps as follows:

- ignored except during the ambiguous hour and during the impossible hour
- during the ambiguous or impossible hour:
  - if True, prefer/pretend DST
  - if False, prefer/pretend non-DST
  - if None, raise an error

Here I'd prefer the default to be None if I had to do it over again,
but given that the current behavior is one of the first two (which
one?) we probably can't do that. Still, it's slightly confusing that
passing None is not the same as omitting the parameter altogether --
there aren't many APIs that explicitly support passing None but don't
use it as the default (though there probably are some precedents).
Maybe requesting an error should be done through some other special
value, and None should be the same as omitted and the same as the old
behavior? But where would the special value come from? It should be
made as easy as possible to "do the right thing" (i.e. raise an
error). Or maybe have a separate Boolean flag to request an error?

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Guido van Rossum]

On Tue, Dec 11, 2012 at 7:19 PM, Barry Warsaw  wrote:
> On Dec 12, 2012, at 01:14 PM, Nick Coghlan wrote:
>
>>That's a backwards compatibility risk, though - many applications are
>>likely coping just fine with the slightly corrupted time values, but would
>>fall over if an exception was raised instead.

Right.

>>The default should probably
>>be chosen so that the single argument form of these calls continues to
>>behave the same in 3.4 as it does in 3.3, emitting a DeprecationWarning to
>>say that the default behaviour is going to change in 3.5 (so the *actual*
>>default would be sentinel value, in order to tell the difference between an
>>explicit True being passed and relying on the default behaviour).
>
> +1

I don't think it's worth deprecating the old behavior.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Barry Warsaw]

On Dec 12, 2012, at 01:14 PM, Nick Coghlan wrote:

>That's a backwards compatibility risk, though - many applications are
>likely coping just fine with the slightly corrupted time values, but would
>fall over if an exception was raised instead. The default should probably
>be chosen so that the single argument form of these calls continues to
>behave the same in 3.4 as it does in 3.3, emitting a DeprecationWarning to
>say that the default behaviour is going to change in 3.5 (so the *actual*
>default would be sentinel value, in order to tell the difference between an
>explicit True being passed and relying on the default behaviour).

+1

Cheers,
-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Nick Coghlan]

On Wed, Dec 12, 2012 at 12:58 PM, Barry Warsaw  wrote:

> On Dec 11, 2012, at 04:23 PM, Lennart Regebro wrote:
>
> >A new ``is_dst`` parameter is added to several of the `tzinfo` methods to
> >handle time ambiguity during DST changeovers.
>
> >``None`` will raise an ``AmbiguousTimeError`` exception if the time
> specified
> >was during a DST change over. It will also raise a
> ``NonExistentTimeError``
> >if a time is specified during the "missing time" in a change to DST.
>
> I think None should be the default.
>

That's a backwards compatibility risk, though - many applications are
likely coping just fine with the slightly corrupted time values, but would
fall over if an exception was raised instead. The default should probably
be chosen so that the single argument form of these calls continues to
behave the same in 3.4 as it does in 3.3, emitting a DeprecationWarning to
say that the default behaviour is going to change in 3.5 (so the *actual*
default would be sentinel value, in order to tell the difference between an
explicit True being passed and relying on the default behaviour).


Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Barry Warsaw]

On Dec 11, 2012, at 04:23 PM, Lennart Regebro wrote:

>A new ``is_dst`` parameter is added to several of the `tzinfo` methods to
>handle time ambiguity during DST changeovers.

>``None`` will raise an ``AmbiguousTimeError`` exception if the time specified
>was during a DST change over. It will also raise a ``NonExistentTimeError``
>if a time is specified during the "missing time" in a change to DST.

I think None should be the default.

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Barry Warsaw]

On Dec 11, 2012, at 03:31 PM, Barry Warsaw wrote:

>I've assigned this PEP 431, reformatted a few extra wide paragraphs, committed
>and pushed.

Unfortunately, it looks like the online PEP updater isn't working.

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Barry Warsaw]

On Dec 11, 2012, at 03:37 PM, Brandon W Maister wrote:

>Barry you want github raw:
>https://raw.github.com/regebro/tz-pep/master/pep-04tz.txt

I found that out.  I was mostly just complaining. ;)

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Barry Warsaw]

On Dec 11, 2012, at 03:48 PM, Paul Moore wrote:

>I agree. Also, in corporate or similar environments where each
>individual package installation must be approved, having at least some
>timezone data in the base install ensures that all Python code can
>assume the *existence* of timezone support (if not necessarily the
>accuracy of that data).

One other thing that the PEP should describe is what happens on a distro that
has timezone data, but which you also pip install the PyPI tzdata package.
Which one wins?  Is there a way to control it, other than providing an
explicit path?  Is there a way to uninstall the PyPI package?  Does the API
need to provide a method which tells you where the database it is using by
default lives?

Cheers,
-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Barry Warsaw]

Great work, Lennart.  I really like this PEP.  Feedback follows (I haven't yet
read the rest of the messages in this thread ;).

On Dec 11, 2012, at 04:23 PM, Lennart Regebro wrote:

>This PEP proposes to add these ``is_dst`` parameters to the relevant methods
>of the ``datetime`` API, and therefore add this functionality directly to
>``datetime``. This is likely the hardest part of this PEP as this
>involves updating
>the

Oops, something got cut off there.

>The new ``timezone``-module
>---
>
>The public API of the new ``timezone``-module contains one new class, one new
>function and one new exception.

Why add a new module instead of putting all this into the existing datetime
module, either directly or as a submodule?  Seems like the obvious place to
put it instead of claiming another top-level module name.

>* New class: ``DstTzInfo``
>
>  This class provides a concrete implementation of the ``zoneinfo`` base
>  class that implements DST support.

Is this a subclass of datetime.tzinfo?

>* New function :``get_timezone(name=None, db=None)``
>
>  This function takes a name string that must be a string specifying a
>  valid zoneinfo timezone, ie "US/Eastern", "Europe/Warsaw" or "Etc/GMT+11".
>  If not given, the local timezone will be looked up. If an invalid zone name
>  are given, or the local timezone can not be retrieved, the function raises
>  `UnknownTimeZoneError`.
>
>  The function also takes an optional path to the location of the zoneinfo
>  database which should be used. If not specified, the function will check if
>  the `timezonedata` module is installed, and then use that location or
>  otherwise use the database in ``/usr/share/zoneinfo``.

I'm bikeshedding, but can we find a better name than `db` for the second
argument?  Something that makes it obvious we're looking for file system path?

>* New Exception: ``UnknownTimeZoneError``

I'd really like to see a TimeZoneError base class from which all these new
exceptions inherit.

>A new ``is_dst`` parameter is added to several of the `tzinfo` methods to
>handle time ambiguity during DST changeovers.
>
>* ``tzinfo.utcoffset(self, dt, is_dst=True)``

I lied a little bit - I did skim the other messages, so I'll reserve comment
on the default value of is_dst for follow ups.

>* ``AmbiguousTimeError``
>
>* ``NonExistentTimeError``

I'm not positive we need separate exceptions here, but I guess it can't hurt,
and with the base class idea above, we can catch both either explicitly, or by
catching the base class.
>
>The ``timezonedata``-package
>-

Just to be clear, this doesn't expose any new modules, right?

Cheers,
-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Robert Brewer]

Guido van Rossum wrote:
> Sent: Tuesday, December 11, 2012 4:11 PM
> To: Antoine Pitrou
> Cc: python-dev@python.org
> Subject: Re: [Python-Dev] Draft PEP for time zone support.
> 
> On Tue, Dec 11, 2012 at 8:07 AM, Antoine Pitrou 
> wrote:
> > Le Tue, 11 Dec 2012 16:23:37 +0100,
> > Lennart Regebro  a écrit :
> >>
> >> Changes in the ``datetime``-module
> >> --
> >>
> >> A new ``is_dst`` parameter is added to several of the `tzinfo`
> >> methods to handle time ambiguity during DST changeovers.
> >>
> >> * ``tzinfo.utcoffset(self, dt, is_dst=True)``
> >>
> >> * ``tzinfo.dst(self, dt, is_dst=True)``
> >>
> >> * ``tzinfo.tzname(self, dt, is_dst=True)``
> >>
> >> The ``is_dst`` parameter can be ``True`` (default), ``False``, or
> >> ``None``.
> >>
> >> ``True`` will specify that the given datetime should be interpreted
> >> as happening during daylight savings time, ie that the time
> specified
> >> is before the change from DST.
> >
> > Why is it True by default? Do we have statistics showing that Python
> > gets more use in summer?
> 
> My question exactly.

"Summer" in the USA, at least, is 238 days in 2012, while "Winter" into 2013 is 
only 126 days:

>>> import datetime
>>> datetime.date(2012, 11, 4) - datetime.date(2012, 3, 11)
datetime.timedelta(238)
>>> datetime.date(2013, 3, 10) - datetime.date(2012, 11, 4)
datetime.timedelta(126)


Robert Brewer
fuman...@aminus.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Nick Coghlan]

On Wed, Dec 12, 2012 at 1:23 AM, Lennart Regebro  wrote:

> Abstract
> 
>
> This PEP proposes the implementation of concrete time zone support in the
> Python standard library, and also improvements to the time zone API to deal
> with ambiguous time specifications during DST changes.
>

Thanks for tackling this one, Lennart.


> Proposal
> 
>
> Concrete time zone support
> --
>
> The time zone support in Python has no concrete implementation in the
> standard library, only a tzinfo baseclass, and since Python 3.2, one
> concrete
> time zone: UTC.


This isn't quite right - the current concrete timezones support any fixed
offset from UTC, not just UTC itself.
http://docs.python.org/3/library/datetime#timezone-objects

(Although there a couple of bugs in those docs at the moment:
http://bugs.python.org/issue16667)


> The time zone support will be implemented by a new module called
> `timezone``,
> based on Stuart Bishop's ``pytz`` module.
>

Ick, why a new module? Why not just add this directly to datetime? (It
doesn't need to be provided by the C accelerator, it can go straight in the
pure Python part).


> This PEP proposes to add these ``is_dst`` parameters to the relevant
> methods
> of the ``datetime`` API, and therefore add this functionality directly to
> ``datetime``. This is likely the hardest part of this PEP as this
> involves updating
> the
>

Missing the end of this sentence...


> The ``timezonedata``-package
> -
>
> The zoneinfo database will be packaged for easy installation with
> ``easy_install``/``pip``/``buildout``. This package will not install any
> Python code, and will not contain any Python code except that which is
> needed
> for installation.
>

I'd prefer a more aggressive name for this like "tzdata_override". My
rationale is that *nix users need to thoroughly aware that if they install
this package, they will stop benefiting from the automatic tz database
updates provided by their OS (especially if they install it into the system
site packages on a distro that has migrated to Python 3 for system tools).

Such a name would also make it possible to provide *two* packaged
databases, one checked before the OS data (tzdata_override), and one
shipped with Python itself that is used only if the OS doesn't provide the
timezone database (tzdata_fallback). tzdata_fallback would then be updated
to the latest Olsen database for each maintenance release. Cross-platform
applications that wanted more reliably up to date timezone data could then
conditionally depend on tzdata_override for Windows deployments (using the
environment marker support in metadata 1.2+).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Guido van Rossum]

On Tue, Dec 11, 2012 at 8:07 AM, Antoine Pitrou  wrote:
> Le Tue, 11 Dec 2012 16:23:37 +0100,
> Lennart Regebro  a écrit :
>>
>> Changes in the ``datetime``-module
>> --
>>
>> A new ``is_dst`` parameter is added to several of the `tzinfo`
>> methods to handle time ambiguity during DST changeovers.
>>
>> * ``tzinfo.utcoffset(self, dt, is_dst=True)``
>>
>> * ``tzinfo.dst(self, dt, is_dst=True)``
>>
>> * ``tzinfo.tzname(self, dt, is_dst=True)``
>>
>> The ``is_dst`` parameter can be ``True`` (default), ``False``, or
>> ``None``.
>>
>> ``True`` will specify that the given datetime should be interpreted
>> as happening during daylight savings time, ie that the time specified
>> is before the change from DST.
>
> Why is it True by default? Do we have statistics showing that Python
> gets more use in summer?

My question exactly.

The rest sounds good -- definitely use the system tz database on Unixy
systems, pre-install on Windows and make updating easy. Some
bikeshedding about static I don't really understand, so I'll leave to
others.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Brandon W Maister]

Barry you want github raw:
https://raw.github.com/regebro/tz-pep/master/pep-04tz.txt


On Tue, Dec 11, 2012 at 3:31 PM, Barry Warsaw  wrote:

> On Dec 11, 2012, at 04:23 PM, Lennart Regebro wrote:
>
> >This PEP is also available on github:
> >
> >https://github.com/regebro/tz-pep/blob/master/pep-04tz.txt
>
> wget returns some html gobbledygook.  Why-oh-why github?!
>
> >PEP: 4??
>
> I've assigned this PEP 431, reformatted a few extra wide paragraphs,
> committed
> and pushed.
>
> Thanks Lennart!
> -Barry
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/quodlibetor%40gmail.com
>
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Donald Stufft]

On Tuesday, December 11, 2012 at 3:31 PM, Barry Warsaw wrote:
> On Dec 11, 2012, at 04:23 PM, Lennart Regebro wrote:
> 
> > This PEP is also available on github:
> > 
> > https://github.com/regebro/tz-pep/blob/master/pep-04tz.txt
> 
> wget returns some html gobbledygook. Why-oh-why github?!'
wget https://raw.github.com/regebro/tz-pep/master/pep-04tz.txt 
> 
> > PEP: 4??
> 
> I've assigned this PEP 431, reformatted a few extra wide paragraphs, committed
> and pushed.
> 
> Thanks Lennart!
> -Barry
> 
> ___
> Python-Dev mailing list
> Python-Dev@python.org (mailto:Python-Dev@python.org)
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/donald.stufft%40gmail.com
> 
> 


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Barry Warsaw]

On Dec 11, 2012, at 04:23 PM, Lennart Regebro wrote:

>This PEP is also available on github:
>
>https://github.com/regebro/tz-pep/blob/master/pep-04tz.txt

wget returns some html gobbledygook.  Why-oh-why github?!

>PEP: 4??

I've assigned this PEP 431, reformatted a few extra wide paragraphs, committed
and pushed.

Thanks Lennart!
-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Antoine Pitrou]

Le Tue, 11 Dec 2012 16:23:37 +0100,
Lennart Regebro  a écrit :
> 
> Changes in the ``datetime``-module
> --
> 
> A new ``is_dst`` parameter is added to several of the `tzinfo`
> methods to handle time ambiguity during DST changeovers.
> 
> * ``tzinfo.utcoffset(self, dt, is_dst=True)``
> 
> * ``tzinfo.dst(self, dt, is_dst=True)``
> 
> * ``tzinfo.tzname(self, dt, is_dst=True)``
> 
> The ``is_dst`` parameter can be ``True`` (default), ``False``, or
> ``None``.
> 
> ``True`` will specify that the given datetime should be interpreted
> as happening during daylight savings time, ie that the time specified
> is before the change from DST.

Why is it True by default? Do we have statistics showing that Python
gets more use in summer?

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Brian Curtin]

On Tue, Dec 11, 2012 at 9:48 AM, Paul Moore  wrote:
> On 11 December 2012 15:39, Dirkjan Ochtman  wrote:
>>> Should the windows installer include the data package?
>>> --
>>>
>>> It has been suggested that the Windows installer should include the data
>>> package. This would mean that an explicit installation no longer would be
>>> needed on Windows. On the other hand, that would mean that many using 
>>> Windows
>>> would not be aware that the database quickly becomes outdated and would not
>>> keep it updated.
>>
>> I still submit that it's pretty much just as easy to forget to update
>> the database whether it's been installed by hand zero or one times, so
>> I don't find your argument convincing. I don't mind the result much,
>> though.
>
> I agree. Also, in corporate or similar environments where each
> individual package installation must be approved, having at least some
> timezone data in the base install ensures that all Python code can
> assume the *existence* of timezone support (if not necessarily the
> accuracy of that data).
>
> If the base Windows installer does not include timezone data, then the
> documentation should note this and offer advice on how to write code
> that degrades gracefully without timezones.
>
> If the base installer *does* include timezone data, of course, there
> should be a documented mechanism for updating it (we don't want magic
> like the old xml package used, I assume).

I think we should try to get the data into the base installer and then
include a small updater, perhaps putting it in a Windows scheduled
task and checking PyPI periodically for newer versions. If a new one
comes up, prompt if the user wants it.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Paul Moore]

On 11 December 2012 15:39, Dirkjan Ochtman  wrote:
>> Should the windows installer include the data package?
>> --
>>
>> It has been suggested that the Windows installer should include the data
>> package. This would mean that an explicit installation no longer would be
>> needed on Windows. On the other hand, that would mean that many using Windows
>> would not be aware that the database quickly becomes outdated and would not
>> keep it updated.
>
> I still submit that it's pretty much just as easy to forget to update
> the database whether it's been installed by hand zero or one times, so
> I don't find your argument convincing. I don't mind the result much,
> though.

I agree. Also, in corporate or similar environments where each
individual package installation must be approved, having at least some
timezone data in the base install ensures that all Python code can
assume the *existence* of timezone support (if not necessarily the
accuracy of that data).

If the base Windows installer does not include timezone data, then the
documentation should note this and offer advice on how to write code
that degrades gracefully without timezones.

If the base installer *does* include timezone data, of course, there
should be a documented mechanism for updating it (we don't want magic
like the old xml package used, I assume).

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Dirkjan Ochtman]

On Tue, Dec 11, 2012 at 4:23 PM, Lennart Regebro  wrote:
> Proposal
> 
>
> The time zone support will be implemented by a new module called `timezone``,
> based on Stuart Bishop's ``pytz`` module.

I wonder if there needs to be something here about how to port from
pytz to the new timezone library.

> * New function :``get_timezone(name=None, db=None)``
>
>   This function takes a name string that must be a string specifying a
>   valid zoneinfo timezone, ie "US/Eastern", "Europe/Warsaw" or "Etc/GMT+11".
>   If not given, the local timezone will be looked up. If an invalid zone name
>   are given, or the local timezone can not be retrieved, the function raises
>   `UnknownTimeZoneError`.
>
>   The function also takes an optional path to the location of the zoneinfo
>   database which should be used. If not specified, the function will check if
>   the `timezonedata` module is installed, and then use that location
> or otherwise
>   use the database in ``/usr/share/zoneinfo``.
>
>   If no database is found an ``UnknownTimeZoneError`` or subclass thereof will
>   be raised with a message explaining that no zoneinfo database can be found,
>   but that you can install one with the ``timezonedata`` package.

It seems like calling get_timezone() with an unknown timezone should
just throw ValueError, not necessarily some custom Exception? It would
probably be a good idea to have a different exception for the case of
no database available.

> Differences from the ``pytz`` API
> =
>
> * ``pytz`` has the functions ``localize()`` and ``normalize()`` to work
>   around that ``tzinfo`` doesn't have is_dst. When ``is_dst`` is
>   implemented directly in ``datetime.tzinfo`` they are no longer needed.
>
> * The ``pytz`` method ``timezone()`` is instead called
> ``get_timezone()`` for clarity.
>
> * ``get_timezone()``  will return the local time zone if called
> without parameters.
>
> * The class ``pytz.StaticTzInfo`` is there to provide the ``is_dst``
> support for static
>   timezones. When ``is_dst`` support is included in
> ``datetime.tzinfo`` it is no longer needed.

This feels a bit superfluous. Why not keep a bit more of the pytz API
to make porting easy? The pytz API has proven itself in the wild, so I
don't see much point in renaming "for clarity". It also seems
relatively painless to keep localize() and normalize() functions
around for easy porting.

> Discussion
> ==
>
> Should the windows installer include the data package?
> --
>
> It has been suggested that the Windows installer should include the data
> package. This would mean that an explicit installation no longer would be
> needed on Windows. On the other hand, that would mean that many using Windows
> would not be aware that the database quickly becomes outdated and would not
> keep it updated.

I still submit that it's pretty much just as easy to forget to update
the database whether it's been installed by hand zero or one times, so
I don't find your argument convincing. I don't mind the result much,
though.

Looking forward to have timezone support in the stdlib!

Cheers,

Dirkjan
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com