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.
> 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:
On Tue, Feb 11, 2020 at 12:59:04AM -0000, Jon Ribbens via Python-list wrote:
> On 2020-02-10, Python <pyt...@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.
Thanks
--
https://mail.python.org/mailman/listinfo/python-list
