Path: csiph.com!eternal-september.org!feeder.eternal-september.org!border1.nntp.ams1.giganews.com!nntp.giganews.com!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!nzpost1.xs4all.net!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.000 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'subject:: [': 0.03; 'modify': 0.04; 'guido': 0.05; 'conversions': 0.07; 'repeated': 0.07; 'seemed': 0.07; 'semantic': 0.07; 'ugly': 0.07; 'cc:addr :python-list': 0.09; 'behavior,': 0.09; 'happen.': 0.09; 'objects.': 0.09; 'received:openend.se': 0.09; 'received:theraft.openend.se': 0.09; 'python': 0.10; '>in': 0.16; '>to': 0.16; 'cc:addr:lac': 0.16; 'cc:addr:openend.se': 0.16; 'cc:name:laura creighton': 0.16; 'dances': 0.16; 'distinct': 0.16; 'from:addr:lac': 0.16; 'from:addr:openend.se': 0.16; 'from:name:laura creighton': 0.16; 'hacks': 0.16; 'lookups': 0.16; 'message-id:@fido.openend.se': 0.16; 'offsets': 0.16; 'peters': 0.16; 'railroad': 0.16; 'received:fido': 0.16; 'received:fido.openend.se': 0.16; 'return,': 0.16; 'skip:> 20': 0.16; 'spit': 0.16; 'uses,': 0.16; 'utc': 0.16; 'yup,': 0.16; 'app': 0.16; 'case.': 0.18; 'resolved': 0.18; ';-)': 0.18; 'subject:] ': 0.19; '>>>': 0.20; 'changes': 0.20; '2015': 0.20; 'cc:addr:python.org': 0.20; 'proposed': 0.20; 'fix': 0.21; 'cc:2**1': 0.22; 'level,': 0.22; 'sep': 0.22; 'subject:skip:i 10': 0.22; 'attached.': 0.23; 'replacing': 0.23; 'second': 0.24; 'tim': 0.24; 'written': 0.24; "doesn't": 0.26; 'appear': 0.26; 'possibility': 0.27; '(e.g.,': 0.27; 'said,': 0.27; 'idea': 0.28; '-0500,': 0.29; 'filed': 0.29; 'received:se': 0.29; 'objects': 0.29; 'themselves': 0.29; 'typically': 0.29; 'there.': 0.30; 'work.': 0.30; 'creating': 0.30; 'solutions.': 0.30; 'somebody': 0.30; 'rules': 0.31; 'possibly': 0.32; 'problem': 0.33; 'common': 0.33; 'schedule': 0.34; 'file': 0.34; 'attempt': 0.35; 'newer': 0.35; 'replace': 0.35; 'skip:> 10': 0.35; 'knowledge': 0.35; 'sometimes': 0.35; 'but': 0.36; 'needed': 0.36; 'there': 0.36; 'possible': 0.36; 'subject:" ': 0.36; 'totally': 0.36; 'subject:?': 0.36; 'really': 0.37; 'two': 0.37; 'charset:us- ascii': 0.37; 'why': 0.39; 'whatever': 0.39; 'does': 0.39; 'enough': 0.39; 'subject:-': 0.39; 'rather': 0.39; 'skip:e 20': 0.39; 'some': 0.40; 'skip:u 10': 0.61; 'header:Message-Id:1': 0.61; 'total': 0.62; 'back': 0.62; 'great': 0.63; 'information': 0.63; 'times': 0.63; 'capture': 0.66; 'past.': 0.66; 'subject:there': 0.66; 'account': 0.66; 'url:v': 0.72; 'special': 0.73; 'url:youtube': 0.73; '>from': 0.76; 'url:watch': 0.78; '>with': 0.84; 'appearance.': 0.84; 'appreciating': 0.84; 'asked.': 0.84; 'fortunate': 0.84; 'header:In-reply-to:1': 0.84; 'subject:any': 0.84; 'notion': 0.91; 'thoroughly': 0.91; 'insane': 0.95; 'subject:Are': 0.95 To: Tim Peters cc: Laura Creighton , Python-List From: Laura Creighton Subject: Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo? In-reply-to: References: <1442085362.324875.381920729.5E7A6DCE@webmail.messagingengine.com> <201509131224.t8DCOXHO004891@fido.openend.se> <201509131600.t8DG07e0025688@fido.openend.se> <201509132031.t8DKVTwJ028027@fido.openend.se> Comments: In-reply-to Tim Peters message dated "Sun, 13 Sep 2015 16:58:09 -0500." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1074.1442219245.1@fido> Date: Mon, 14 Sep 2015 10:27:25 +0200 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.9 (theraft.openend.se [82.96.5.2]); Mon, 14 Sep 2015 10:27:27 +0200 (CEST) X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.20+ Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 67 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1442219257 news.xs4all.nl 23723 [2001:888:2000:d::a6]:45460 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:96559 In a message of Sun, 13 Sep 2015 16:58:09 -0500, Tim Peters writes: >[Tim] >>> Whatever time zone the traveler's railroad schedule uses, so long as >>> it sticks to just one > >[Laura] >> This is what does not happen. Which is why I have written a python >> app to perform conversions for my parents, in the past. > >So how did they get the right time zone rules for Creighton? I was fortunate enough that they were never going there. But in investigating the problem I had it filed away under 'really ugly hacks I might have to write in the future'. Pre-parsing the file with special mappings for special lookups seemed the only way to fix this, at the time, but we have newer databases now than I had then ... some of which might already know about Creighton. >pytz solves it by _never_ creating a hybrid tzinfo. It only uses >eternally-fixed-offset tzinfos. For example, for a conceptual zone >with two possible total UTC offsets (one for "daylight", one for >"standard"), there two distinct eternally-fixed-offset tzinfo objects >in pytz. Then an ambiguous time is resolved by _which_ specific >tzinfo object is attached. Typically the "daylight" tzinfo for the >first time a repeated local time appears, and the "standard" tzinfo >for its second appearance. Yes. I think this is a really great idea. I have no idea why other people disagree. >In return, you have to use .localize() and .normalize() at various >times, because pytz's tzinfo objects themselves are completely blind >to the possibility of the total UTC offset changing. .localize() and >.normalize() are needed to possibly _replace_ the tzinfo object in >use, depending on the then-current date and time. Yes. >OTOH, `dateutil` does create hybrid tzinfo objects. No dances are >ever needed to possibly replace them. But it's impossible for >dateutil's tzinfos to disambiguate times in a fold. Incidentally, >dateutil also makes no attempt to account for transitions other than >DST (e.g., sometimes a zone may change its _base_ ("standard") offset >from UTC). I find this totally unacceptable. My conclusion was that hybrid tzinfo objects were a _really stupid idea_ proposed by somebody who misunderstood the problem, or rather only understood the most common case. Smack them with a dead fish, https://www.youtube.com/watch?v=i9SSOWORzw4 and get back to work. >So, yup, if you're thoroughly indoctrinated in pytz behavior, you will >be accurate but appear insane to Guido ;-) At a semantic level, a >pytz tzinfo doesn't capture the notion of a zone with offset changes - >it doesn't even try to. All knowledge about offset changes is inside >the .localize() and .normalize() dances. I can see why people would like to modify it to spit out this information when asked. I don't understand why they would like to have a hybrid tzinfo. The notion of replacing tzinfos when they become inappropriate fills their souls with revulsion, or something? But, as I said, once you know the pytz way you may be ruined for appreciating other solutions.