DateAxisItem timezone offsets?

53 views
Skip to first unread message

mks

unread,
Jun 12, 2020, 8:02:26 AM6/12/20
to pyqtgraph
Hello all,

I was about to open an issue on GitHub, but I thought I may ask here first, perhaps I just misunderstood how this object works.

On line 214 in `DateAxisItem.py` I can see that local time timezone is used:

self.utcOffset = time.timezone

Which is then used to offset dates on the axis as seen on line 229:

dates = [utcfromtimestamp(v - self.utcOffset) for v in values]

I found this to be a problem in my application and to be honest I don't understand why would this be desirable as default behavior. Shouldn't we use the date as provided by the data, including its timezone, unless explicitly stating otherwise?

In my specific use case, I rely on accurate x axis datetime values to position different GraphicsObjects. These objects have parametrized width, which is expressed as fractions of a timeunit, which is in turn provided during construction, e.g. these objects can be 0.8-hour-wide padded with 0.1 hour margin on each side or they could be 0.6 day-wide padded with 0.1-day-wide margin on each side shifted to the right by 0.2 of a day etc. In either case, the position is calculated from data's own timestamp, which is in UTC. Current DateAxisItem functionality causes my objects to be shifted by 2 hours, since that is an offset between my current time zone and UTC. However, as a frequent traveler, I may find that in a few months this offset would be different.

Looking at the code I don't see the ability to pass desired offset during construction. Do I have to subclass to change that bit? In a more general sense, shouldn't this be parameterized during construction?

Thanks,
mks.

Carlos Pascual-Izarra

unread,
Jun 12, 2020, 12:28:50 PM6/12/20
to pyqt...@googlegroups.com

On 6/12/20 2:02 PM, mks wrote:
> In a more general sense, shouldn't this be parameterized during
> construction?

I haven't looked at the implementation in detail, but your suggestion
makes a lot of sense to me in principle.

Reply all
Reply to author
Forward
0 new messages