Opened 14 years ago
Closed 14 years ago
Last modified 13 years ago
#9937 closed Bug Report - General (fixed)
MythTV datetime class shouldn't have nested tzinfo class
Reported by: | Owned by: | Raymond Wagner | |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | Bindings - Python | Version: | 0.24-fixes |
Severity: | low | Keywords: | |
Cc: | Ticket locked: | no |
Description
MythTV.utility.datetime
has a nested class, tzinfo
. This means the tzinfo
attribute of datetime
instances is the tzinfo
type. However, this attribute is supposed to be a tzinfo
instance. The datetime
library gets confused by this.
It would be better to move tzinfo
out of the datetime
class, so that the tzinfo
attribute can be an instance, or None
.
For example, when MythTV creates a datetime
object using a timestamp, tzinfo
should be None
, as there is no timestamp information. However tzinfo
is the tzinfo
class. A workaround is to copy the datetime
object:
mythtv_time = prog.starttime # for example new_time = datetime.fromtimestamp(mythtv_time.timestamp())
I found this while fixing an issue in mythcal.
Change History (4)
comment:1 Changed 14 years ago by
Status: | new → accepted |
---|
comment:2 Changed 14 years ago by
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
Fix tzinfo handling in custom Python datetime class
Rename timezone class to _tzinfo to prevent conflicts with proper timezone handling. Correct regular expression to parse timezone offsets from ISO8601 format properly.
Fixes #9937
Branch: master Changeset: a606e972c7c3b28811c7bbb9ce82a64f854b271a
comment:3 Changed 14 years ago by
Milestone: | 0.24.1 → 0.24.2 |
---|
Backported to 0.24-fixes in Changeset: cebd10c05ebd7484fdb5a6c9d497803e222623d9
I know there was reason I had to populate the tzinfo block in that class, but I can't recall off hand what that was. Thanks for posting the ticket. I had forgotten the discussion we had about this on the mailing list.