datetime seems to be broken WRT timezones (even when you add them)

[Chris Angelico]

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)
>     documentation.
>
> 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.

https://docs.python.org/3/library/datetime.html#strftime-and-strptime-format-codes

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. :)

ChrisA