datetime seems to be broken WRT timezones (even when you add them)
On Tue, Feb 11, 2020 at 12:31 PM Python <python at bladeshadow.org> wrote:
> On Tue, Feb 11, 2020 at 11:33:54AM +1100, Chris Angelico wrote:
> > [...] instead of using the undocumented and unsupported strftime %s
> > format code
> I'm not sure this characterization is accurate... the docs (for both
> Python 2 and 3) say:
> The full set of format codes supported varies across platforms,
> because Python calls the platform C library?s strftime() function,
> and platform variations are common. To see the full set of format
> codes supported on your platform, consult the strftime(3)
> And %s is surely there... so it is both documented and supported by
> virtue of Python's docs saying that whatever your OS supports is
> supported. But this is largely beside the point.
The C standard mandates a particular set of format codes, quoted in
that page, and %s is not one of them. Also, Python has its own test
suite and it ensures certain behaviours of datetime.strftime, and %s
is not tested there. So from Python's point of view, I stand by the
description of %s as being undocumented and unsupported. It might
happen to work, but if you link Python against a different C standard
library, it could change that behaviour even on the same computer.
> > I've been using the timestamp() method:
> That's the key piece of info. This does appear to work, though still
> not on python2. That, as you say, is my problem. But thankfully Jon
> Ribbens has the save:
Isn't it time to stop going to great effort to support Python 2?
> On Tue, Feb 11, 2020 at 12:59:04AM -0000, Jon Ribbens via Python-list wrote:
> > On 2020-02-10, Python <python at bladeshadow.org> wrote:
> > > So far, so good. However, when you go to use this object, the time it
> > > represents is in fact wrong.
> > Unsurprisingly for a language feature that's been around for nearly
> > 17 years, no it isn't.
> Well, fine, but it is at best not documented as clearly as it could be
> (in the man pages of my system, which is not Python's fault). But
> you've given me what I need to solve my problem:
> > >>>> print dt.strftime("%s")
> > > 1580452245
> > That's asking your libc's strftime to process the time through the
> > "%s" format code [...] If you're using GNU libc however then it uses the time
> > information given and the timezone from the 'TZ' environment variable
> > and returns seconds since the Unix epoch:
> And knowing this, I can get what I need, on Python2 and python3, by
> doing what I was already doing, but setting os.environ["TZ"] = "GMT"
> in the code itself. Sure it's a bit hacky, but it won't matter here,
> and it gets the right answer, which does matter.
Yes, it's very hacky. The sort of hack that deserves a comment with a
TODO in it. :)