On Tue, Feb 11, 2020 at 12:31 PM Python <pyt...@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 <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. > Yes, it's very hacky. The sort of hack that deserves a comment with a TODO in it. :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
