[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<barry at python.org>  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