Software not working
Even after installing the software on my system the software isn’t running. Sent from Windows Mail -- https://mail.python.org/mailman/listinfo/python-list
datetime seems to be broken WRT timezones (even when you add them)
As best I can tell, Python has no means to make use of the system's
timezone info. In order to make datetime "timezone aware", you need
to manually create a subclass of datetime.tzinfo, whose methods return
the correct values for the timezone you care about. In the general
case, this is hard, but since the timezone my dates are in is always
GMT, it's no problem:
class GMT(datetime.tzinfo):
def utcoffset(self, dt):
return datetime.timedelta(hours=0)
def dst(self, dt):
return datetime.timedelta(minutes=0)
def tzname(self, dt):
return "GMT"
Now, you can instantiate a datetime.datetime object with the times you
want, and pass an instance of this class as the tzinfo argument to the
constructor. Also no problem:
>>> dt = datetime.datetime(2020, 1, 31, 1, 30, 45, 987654, GMT())
>>> dt
datetime.datetime(2020, 1, 31, 1, 30, 45, 987654, tzinfo=<__main__.GMT object
at 0x7f9084e2add0>)
>>> print dt
2020-01-31 01:30:45.987654+00:00
Note the tzinfo object, and the +00:00 indicating this is indeed in
GMT. If you create a "naive" datetime object, you don't get that:
>>> xy = datetime.datetime(2020, 1, 31, 1, 30, 45, 987654)
>>> xy
datetime.datetime(2020, 1, 31, 1, 30, 45, 987654)
>>> print xy
2020-01-31 01:30:45.987654
So far, so good. However, when you go to use this object, the time it
represents is in fact wrong. For example:
>>> print dt.strftime("%s")
1580452245
Using the date command, we can easily see that it is incorrect:
# Ask for UTC, gives the wrong time
$ date -u -d "@1580452245"
Fri Jan 31 06:30:45 UTC 2020
# Ask for local time, gives the time I specified... which should have
# been in GMT, but is in my local timezone
$ date -d "@1580452245"
Fri Jan 31 01:30:45 EST 2020
And the correct value should have been:
$ date -d "2020-01-31 1:30:45 GMT" +%s
1580434245
Same results under Python2.7 or Python3.
:( :( :(
I suspect this is because the underlying implementation uses
strftime() which takes struct tm, which has no field to contain the
timezone info, and does not do the necessary conversion before handing
it off. I'm not sure what the date command is doing differently, but
it clearly is able to get the correct answer.
Does Python have an alternative way to do the above, with correct
results?
Thanks
--
https://mail.python.org/mailman/listinfo/python-list
Re: datetime seems to be broken WRT timezones (even when you add them)
> As best I can tell, Python has no means to make use of the system's > timezone info. In order to make datetime "timezone aware", you need > to manually create a subclass of datetime.tzinfo, whose methods return > the correct values for the timezone you care about. > ... > Does Python have an alternative way to do the above, with correct > results? > The datetime module's manipulation of timezones is pretty low-level. Maybe try arrow? https://arrow.readthedocs.io/en/latest/ Skip > -- https://mail.python.org/mailman/listinfo/python-list
Re: Software not working
On 11/02/20 12:00 AM, Tushita Parashar wrote: Even after installing the software on my system the software isn’t running. Today, an (apparently) identical question, already asked and answered. Please see the Python-Tutor list: "Python Beginner" msg. -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: datetime seems to be broken WRT timezones (even when you add them)
On Mon, Feb 10, 2020 at 05:52:59PM -0600, Skip Montanaro wrote: > > As best I can tell, Python has no means to make use of the system's > > timezone info. In order to make datetime "timezone aware", you need > > to manually create a subclass of datetime.tzinfo, whose methods return > > the correct values for the timezone you care about. > > > ... > > > Does Python have an alternative way to do the above, with correct > > results? > > > > The datetime module's manipulation of timezones is pretty low-level. Maybe > try arrow? > > https://arrow.readthedocs.io/en/latest/ Yeah, this looks like exacly what I'm looking for, but I need something that's part of the standard Python distribution, due to constraints I have no control over. [This is perhaps not strictly true, but for all intents and purposes...] FWIW, manipulating dates on POSIX systems is pretty much a nightmare, so it's hard to blame Python entirely for the state of things. Thanks though. -- https://mail.python.org/mailman/listinfo/python-list
Re: datetime seems to be broken WRT timezones (even when you add them)
On Tue, Feb 11, 2020 at 10:42 AM Python wrote: > > As best I can tell, Python has no means to make use of the system's > timezone info. In order to make datetime "timezone aware", you need > to manually create a subclass of datetime.tzinfo, whose methods return > the correct values for the timezone you care about. In the general > case, this is hard, but since the timezone my dates are in is always > GMT, it's no problem: > > class GMT(datetime.tzinfo): > def utcoffset(self, dt): > return datetime.timedelta(hours=0) > def dst(self, dt): > return datetime.timedelta(minutes=0) > def tzname(self, dt): > return "GMT" > > Now, you can instantiate a datetime.datetime object with the times you > want, and pass an instance of this class as the tzinfo argument to the > constructor. Also no problem: Rather than try to create your own GMT() object, have you considered using datetime.timezone.utc ? I tested it in your examples and it works just fine. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: datetime seems to be broken WRT timezones (even when you add them)
On Tue, Feb 11, 2020 at 11:04:28AM +1100, Chris Angelico wrote:
> On Tue, Feb 11, 2020 at 10:42 AM Python wrote:
> > Now, you can instantiate a datetime.datetime object with the times you
> > want, and pass an instance of this class as the tzinfo argument to the
> > constructor. Also no problem:
>
> Rather than try to create your own GMT() object, have you considered
> using datetime.timezone.utc ? I tested it in your examples and it
> works just fine.
Not here it doesn't:
>>> import datetime
>>> dt = datetime.datetime(2020, 1, 31, 1, 30, 45, 987654,
>>> datetime.timezone.utc)
>>> print(dt)
2020-01-31 01:30:45.987654+00:00
>>> print(dt.strftime("%s"))
1580452245
That's the same erroneous result from my example. The correct value
is again 1580434245. Unless you've done something subtlely
different...
Also it's only available on Python3, which may not be the end of the
world, but the tool I'm working on is--for the moment at
least--expected to work on both python2.7 and 3. But it's irrelevant
if it doesn't give the correct result, which seems to still be the
case.
--
https://mail.python.org/mailman/listinfo/python-list
Re: datetime seems to be broken WRT timezones (even when you add them)
On Tue, Feb 11, 2020 at 11:17 AM Python wrote:
>
> On Tue, Feb 11, 2020 at 11:04:28AM +1100, Chris Angelico wrote:
> > On Tue, Feb 11, 2020 at 10:42 AM Python wrote:
> > > Now, you can instantiate a datetime.datetime object with the times you
> > > want, and pass an instance of this class as the tzinfo argument to the
> > > constructor. Also no problem:
> >
> > Rather than try to create your own GMT() object, have you considered
> > using datetime.timezone.utc ? I tested it in your examples and it
> > works just fine.
>
> Not here it doesn't:
>
> >>> import datetime
> >>> dt = datetime.datetime(2020, 1, 31, 1, 30, 45, 987654,
> >>> datetime.timezone.utc)
> >>> print(dt)
> 2020-01-31 01:30:45.987654+00:00
> >>> print(dt.strftime("%s"))
> 1580452245
>
> That's the same erroneous result from my example. The correct value
> is again 1580434245. Unless you've done something subtlely
> different...
I haven't verified the arithmetic or that the date command is actually
giving the result you want/expect here, but in my testing, I got what
looked like correct results. However, instead of using the
undocumented and unsupported strftime %s format code, I've been using
the timestamp() method:
https://docs.python.org/3/library/datetime.html#datetime.datetime.timestamp
rosuav@sikorsky:~$ cat utctest.py
import datetime
dt = datetime.datetime(2020, 1, 31, 1, 30, 45, 987654, datetime.timezone.utc)
print(dt)
print(dt.timestamp())
rosuav@sikorsky:~$ python3.9 utctest.py
2020-01-31 01:30:45.987654+00:00
1580434245.987654
rosuav@sikorsky:~$ python3.8 utctest.py
2020-01-31 01:30:45.987654+00:00
1580434245.987654
rosuav@sikorsky:~$ python3.7 utctest.py
2020-01-31 01:30:45.987654+00:00
1580434245.987654
rosuav@sikorsky:~$ python3.6 utctest.py
2020-01-31 01:30:45.987654+00:00
1580434245.987654
rosuav@sikorsky:~$ python3.5 utctest.py
2020-01-31 01:30:45.987654+00:00
1580434245.987654
rosuav@sikorsky:~$ python3.4 utctest.py
2020-01-31 01:30:45.987654+00:00
1580434245.987654
My interpretation is that, on your platform, strftime("%s") is broken
in the presence of tzinfo.
> Also it's only available on Python3, which may not be the end of the
> world, but the tool I'm working on is--for the moment at
> least--expected to work on both python2.7 and 3. But it's irrelevant
> if it doesn't give the correct result, which seems to still be the
> case.
>
That may be your problem, but it's not mine, and I'm not going to
attempt to answer for Python 2.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: datetime seems to be broken WRT timezones (even when you add them)
On 2020-02-10, Python 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.
> For example:
>
print dt.strftime("%s")
> 1580452245
That's asking your libc's strftime to process the time through the
"%s" format code, which has no defined behaviour under either Python
or POSIX. 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:
>>> dt.strftime('%s')
'1580452245'
>>> import os
>>> os.environ['TZ'] = 'UTC'
>>> dt.strftime('%s')
'1580434245'
If you need to know the seconds since the epoch then in Python 3.3+
you can do that with dt.timestamp(). In Python 2.7 you can use the UTC
class you created:
(dt - datetime(1970, 1, 1, 0, 0, 0, 0, GMT())).total_seconds()
--
https://mail.python.org/mailman/listinfo/python-list
Re: datetime seems to be broken WRT timezones (even when you add them)
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 -, Jon Ribbens via Python-list wrote:
> On 2020-02-10, Python 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
Re: datetime seems to be broken WRT timezones (even when you add them)
On Tue, Feb 11, 2020 at 12:31 PM Python 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 -, Jon Ribbens via Python-list wrote:
> > On 2020-02-10, Python 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
