Path: csiph.com!eternal-september.org!feeder.eternal-september.org!border1.nntp.ams1.giganews.com!nntp.giganews.com!newsfeed.xs4all.nl!newsfeed8.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.005 X-Spam-Evidence: '*H*': 0.99; '*S*': 0.00; 'subject:: [': 0.03; 'remind': 0.05; '"as': 0.07; 'acceptance': 0.07; 'variant': 0.07; 'cc:addr:python-list': 0.09; 'spec': 0.09; 'python': 0.10; 'argument': 0.15; '(either': 0.16; 'arithmetic.': 0.16; 'attractions,': 0.16; 'bundles': 0.16; 'contingent': 0.16; 'magic': 0.16; 'module:': 0.16; 'zone.': 0.16; ';-)': 0.18; 'subject:] ': 0.19; 'windows': 0.20; 'cc:addr:python.org': 0.20; 'cc:2**2': 0.20; 'clock': 0.22; 'subject:skip:i 10': 0.22; 'attach': 0.23; 'tried': 0.24; 'header:In-Reply-To:1': 0.24; 'installed': 0.26; 'sense': 0.26; 'followed': 0.27; 'least': 0.27; 'message-id:@mail.gmail.com': 0.27; 'interface': 0.29; 'always,': 0.29; 'arithmetic': 0.29; 'pep': 0.29; 'rules': 0.31; 'functional': 0.32; 'skip:. 10': 0.32; 'third': 0.33; 'case,': 0.34; 'changing': 0.34; 'except': 0.34; 'received:google.com': 0.35; 'so,': 0.35; 'but': 0.36; 'too': 0.36; 'should': 0.36; 'there': 0.36; 'subject:" ': 0.36; 'subject:?': 0.36; 'method': 0.37; 'difference': 0.38; "won't": 0.38; 'anything': 0.38; 'someone': 0.38; 'end': 0.39; 'why': 0.39; 'system.': 0.39; 'subject:-': 0.39; 'your': 0.60; 'default': 0.61; 'details': 0.62; 'skip:n 10': 0.62; 'within': 0.64; 'believe': 0.66; 'intent': 0.66; 'subject:there': 0.66; 'approaches': 0.72; 'completing': 0.72; '495': 0.84; 'subject:any': 0.84; 'approach.': 0.91; 'subject:Are': 0.95 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=XKFzyX+RB1xWKs8LXepGuTRNe5CYfOfUrCIiQ0Q1sKM=; b=eLPWZJ8JhcOtX0PLjYYEljRQ0b5zDGMDL0rTklNtdJEpzKuwMuqcc2sE2L/YLmWbt5 kWnP13FI9ceUFBx3Zz436ZxtK6K39d1FBOj5IrMHfwpBkClt7b6wYkkE70G2iulkIJ/l 8rFBZA/f0yFzFXWY7FJ9Doz0IabZNKYOj4p35BdCf36kTJMIcMSZ+wTQZUGfvJdgbNdB tfLG9l2oJ8MBS92P3i8qzVxo9BuwSXaUzodS5mCW99vTKBYZeEUeqT6A2CxWTsX5eF2q +x6Jtds7+cY/3FuTiM3VfDswh+kidnx4KDanZ4Dp1eKuCy3wpSS7JHW9hiapy10zmUcL adUg== X-Received: by 10.182.168.114 with SMTP id zv18mr5192118obb.84.1442109543336; Sat, 12 Sep 2015 18:59:03 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <1442085362.324875.381920729.5E7A6DCE@webmail.messagingengine.com> From: Tim Peters Date: Sat, 12 Sep 2015 20:58:48 -0500 Subject: Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo? To: Alexander Belopolsky Cc: Guido van Rossum , Python-List , datetime-sig Content-Type: text/plain; charset=UTF-8 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: 41 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1442109551 news.xs4all.nl 23839 [2001:888:2000:d::a6]:48159 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:96478 [Guido] >> Those pytz methods work for any (pytz) timezone -- astimezone() with a >> default argument only works for the local time zone. {Alex] > That's what os.environ['TZ'] = zonename is for. The astimezone() method > works for every timezone installed on your system. Try it - you won't even > need to call time.tzset()! I tried it. It makes no difference to anything for me. I stay on Windows to remind people that millions of Python users don't see any of the horrid nonsense Linuxish systems force on poor users ;-) > ... > In any case, there are three approaches to designing a TZ database interface > in the datetime module: the "as intended" approach, the pytz approach and > the astimezone(zonename:str) approach. Portability rules out #3, unless Python bundles its own zoneinfo wrapping. pytk's approach has many attractions, like no need for `fold` and no breakage of anything, and blazing fast .utcoffset(). Except at least arithmetic would have to be patched to do a `normalize` variant by magic (to attach the now-appropriate fixed-offset tzinfo, but without changing the clock in the process). Alas, that would be a huge speed hit for classic arithmetic. So, as always, the original intent is the only one that makes sense in the end ;-) > ... > That's why I believe PEP 495 followed by the implementation > of fold-aware "as intended" tzinfos (either within stdlib or by third > parties) is the right approach. Me too - except I think acceptance of 495 should be contingent upon someone first completing a fully functional (if not releasable) fold-aware zoneinfo wrapping. Details have a way of surprising, and we should learn from the last time we released a tzinfo spec in the absence of any industrial-strength wrappings using it.