Path: csiph.com!eternal-september.org!feeder.eternal-september.org!border1.nntp.ams1.giganews.com!nntp.giganews.com!bcyclone03.am1.xlned.com!bcyclone03.am1.xlned.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.001 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'subject:: [': 0.03; 'defined,': 0.09; 'newly': 0.09; 'received:internal': 0.09; 'spelling': 0.09; 'sfxlen:2': 0.10; 'python': 0.10; 'appropriate': 0.14; 'value.': 0.15; 'ends,': 0.16; 'flag).': 0.16; 'message- id:@webmail.messagingengine.com': 0.16; 'peters': 0.16; 'posix': 0.16; 'received:10.202': 0.16; 'received:10.202.2': 0.16; 'received:66.111': 0.16; 'received:66.111.4': 0.16; 'received:messagingengine.com': 0.16; 'utc': 0.16; 'wrote:': 0.16; 'variable': 0.18; 'subject:] ': 0.19; 'to:2**1': 0.21; 'sep': 0.22; 'struct': 0.22; 'subject:skip:i 10': 0.22; '(or': 0.23; 'seems': 0.23; 'attach': 0.23; 'tim': 0.24; 'header:In-Reply- To:1': 0.24; 'mon,': 0.24; 'sort': 0.25; "doesn't": 0.26; 'equivalent': 0.27; 'not.': 0.27; '14,': 0.27; 'converting': 0.27; 'specify': 0.27; 'values': 0.28; 'environment': 0.29; 'convert': 0.29; 'starts': 0.29; 'fixed': 0.31; 'included': 0.32; 'changing': 0.34; 'gets': 0.35; 'so,': 0.35; 'behind': 0.35; "isn't": 0.35; 'according': 0.36; 'but': 0.36; 'serve': 0.36; 'subject:" ': 0.36; 'to:addr:python-list': 0.36; 'subject:?': 0.36; 'received:10': 0.37; 'no,': 0.38; 'received:66': 0.38; 'subject:-': 0.39; 'skip:e 20': 0.39; 'to:addr:python.org': 0.40; 'ever': 0.60; 'your': 0.60; 'header:Message-Id:1': 0.61; 'total': 0.62; 'course': 0.62; 'subject:there': 0.66; 'applying': 0.70; 'flag.': 0.84; 'subject:any': 0.84; 'subject:Are': 0.95 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=ycT+KcHcBMDsW96vdfwK8Hulcys=; b=TQKvhI lFw962wgDbk6y1magatdAR+XE+omEjFEJX4eV4jrLpL6JY85eiH2xcEEPIm/j91/ XeU++OT2o+10AAcWrj+NKKtNYvYqoEBUhURwm6NJ/6L9oWpQftwDaI+V7HO9IMC/ iMZdFmUkENXQi+UuEcv/HctZW/TW5y++7z8Gs= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=ycT+KcHcBMDsW96 vdfwK8Hulcys=; b=hOgugCVM8dxj/BmZo6QxO7pJGErTIso7WUUt6/R4zHZaoMy ffs6Vi4pgd0B5GiaJfzT7j5qxonw0HgC9LK51wzL1X+eGzZJ2MiHTF5ZNJ9aARSd pcYGSVEAkkDr9c9vJQRU/boHxTyKadEiN4bP6P52NXzELM/YoqF0AHAdwSSY= X-Sasl-Enc: qC0fgDkc4+c1H/HssnbbbtKGrUawjxONf0VPUM6Edr3Z 1442257996 From: Random832 To: python-list@python.org, "datetime-sig" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-c76b43ce Subject: Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo? Date: Mon, 14 Sep 2015 15:13:16 -0400 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> <201509140827.t8E8RPqb001076@fido.openend.se> 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: 24 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1442257999 news.xs4all.nl 23754 [2001:888:2000:d::a6]:59970 X-Complaints-To: abuse@xs4all.nl X-Received-Bytes: 6474 X-Received-Body-CRC: 1604478113 Xref: csiph.com comp.lang.python:96589 On Mon, Sep 14, 2015, at 14:53, Tim Peters wrote: > So, on your own machine, whenever daylight time starts or ends, you > manually change your TZ environment variable to specify the newly > appropriate eternally-fixed-offset zone? Of course not. No, but the hybrid zone isn't what gets attached to the individual struct tm value when you convert a time from utc (or from a POSIX timestamp) to a timezone local value. A single fixed utc offset is (along with the name and, yes, isdst flag). And pytz doesn't involve manually changing anything, it involves (as best it can) automatically applying the value to attach to each individual datetime value. > A datetime object is the Python spelling of a C struct tm, but never > included the tm_isdst flag. And no-one behind this proposal seems to be contemplating adding an equivalent to tm_gmtoff, despite that it would serve the same disambiguation purpose and make it much cheaper to maintain global invariants like a sort order according to the UTC value (No, I don't *care* how that's not how it's defined, it is *in fact* true for the UTC value that you will ever actually get from converting the values to UTC *today*, and it's the only total ordering that actually makes any sense)