Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #93305 > unrolled thread

Matplotlib X-axis timezone trouble

Back to article view | Back to comp.lang.python

Contents

  Matplotlib X-axis timezone trouble Peter Pearson <pkpearson@nowhere.invalid> - 2015-06-30 00:56 +0000
    Re: Matplotlib X-axis timezone trouble Laura Creighton <lac@openend.se> - 2015-06-30 04:03 +0200
      Re: Matplotlib X-axis timezone trouble Peter Pearson <pkpearson@nowhere.invalid> - 2015-06-30 04:57 +0000
    Re: Matplotlib X-axis timezone trouble Chris Angelico <rosuav@gmail.com> - 2015-06-30 12:11 +1000
      Re: Matplotlib X-axis timezone trouble Peter Pearson <pkpearson@nowhere.invalid> - 2015-06-30 04:49 +0000
        Re: Matplotlib X-axis timezone trouble Chris Angelico <rosuav@gmail.com> - 2015-06-30 17:01 +1000
          Re: Matplotlib X-axis timezone trouble Peter Pearson <pkpearson@nowhere.invalid> - 2015-06-30 16:42 +0000
            Re: Matplotlib X-axis timezone trouble Chris Angelico <rosuav@gmail.com> - 2015-07-01 02:55 +1000
    Re: Matplotlib X-axis timezone trouble Peter Pearson <pkpearson@nowhere.invalid> - 2015-07-01 05:50 +0000
      Re: Matplotlib X-axis timezone trouble Chris Angelico <rosuav@gmail.com> - 2015-07-01 17:15 +1000
        Datetime timezone trouble (was: Matplotlib X-axis timezone trouble) Peter Pearson <pkpearson@nowhere.invalid> - 2015-07-01 16:36 +0000
          Re: Datetime timezone trouble (was: Matplotlib X-axis timezone trouble) Ian Kelly <ian.g.kelly@gmail.com> - 2015-07-01 10:55 -0600
            Re: Datetime timezone trouble (was: Matplotlib X-axis timezone trouble) Peter Pearson <pkpearson@nowhere.invalid> - 2015-07-01 19:09 +0000
          Re: Datetime timezone trouble (was: Matplotlib X-axis timezone trouble) Chris Angelico <rosuav@gmail.com> - 2015-07-02 03:08 +1000
    Re: Matplotlib X-axis timezone trouble Akira Li <4kir4.1i@gmail.com> - 2015-07-04 07:29 +0300
      Re: Matplotlib X-axis timezone trouble [SOLVED] Peter Pearson <pkpearson@nowhere.invalid> - 2015-07-04 17:37 +0000
    Re: Matplotlib X-axis timezone trouble Tony the Tiger <tony@tiger.invalid> - 2015-07-09 19:50 +0000
      Re: Matplotlib X-axis timezone trouble Peter Pearson <pkpearson@nowhere.invalid> - 2015-07-10 16:15 +0000

#93305 — Matplotlib X-axis timezone trouble

The following code produces a plot with a line running from (9:30, 0) to
(10:30, 1), not from (8:30, 0) to (9:30, 1) as I desire.

If I use timezone None instead of pacific, the plot is as desired, but
of course that doesn't solve the general problem of which this is a
much-reduced example.

If I use timezone US/Central, I get the same (bad) plot.

import matplotlib.pyplot as plt
import datetime
import pytz
pacific = pytz.timezone("US/Pacific")
fig = plt.figure()
plt.plot([datetime.datetime(2014, 10, 7, 8, 30, tzinfo=pacific),
          datetime.datetime(2014, 10, 7, 9, 30, tzinfo=pacific)],
         [0,1], marker="o", color="green")
fig.autofmt_xdate()
plt.show()

Does anybody know why this shift is occurring?  Is Matplotlib
confused about what timezone to use in labeling the axis?  How
would I tell it what timezone to use (preferably explicitly in
the code, not in matplotlibrc)?

Thanks.

-- 
To email me, substitute nowhere->runbox, invalid->com.

[toc] | [next] | [standalone]

#93307

In a message of 30 Jun 2015 00:56:26 +0000, Peter Pearson writes:
>The following code produces a plot with a line running from (9:30, 0) to
>(10:30, 1), not from (8:30, 0) to (9:30, 1) as I desire.
>
>If I use timezone None instead of pacific, the plot is as desired, but
>of course that doesn't solve the general problem of which this is a
>much-reduced example.
>
>If I use timezone US/Central, I get the same (bad) plot.
>
>import matplotlib.pyplot as plt
>import datetime
>import pytz
>pacific = pytz.timezone("US/Pacific")
>fig = plt.figure()
>plt.plot([datetime.datetime(2014, 10, 7, 8, 30, tzinfo=pacific),
>          datetime.datetime(2014, 10, 7, 9, 30, tzinfo=pacific)],
>         [0,1], marker="o", color="green")
>fig.autofmt_xdate()
>plt.show()
>
>Does anybody know why this shift is occurring?  Is Matplotlib
>confused about what timezone to use in labeling the axis?  How
>would I tell it what timezone to use (preferably explicitly in
>the code, not in matplotlibrc)?
>
>Thanks.
>
>-- 
>To email me, substitute nowhere->runbox, invalid->com.
>-- 
>https://mail.python.org/mailman/listinfo/python-list


I know that your problem is that all your times are in UTC, even
though you do not want this.  I had this too.  I forget what I did.

I do not know if this solution from stackoverflow.com will work for
you -- it is definitely different from what I did, but that does
not in any way make it wrong.  Try and see?  and report back?

http://stackoverflow.com/questions/4485607/matplotlib-plot-date-keeping-times-in-utc-even-with-custom-timezone

[toc] | [prev] | [next] | [standalone]

#93311

On Tue, 30 Jun 2015 04:03:57 +0200, Laura Creighton <lac@openend.se> wrote:
> In a message of 30 Jun 2015 00:56:26 +0000, Peter Pearson writes:
>>The following code produces a plot with a line running from (9:30, 0) to
>>(10:30, 1), not from (8:30, 0) to (9:30, 1) as I desire.
>>
>>If I use timezone None instead of pacific, the plot is as desired, but
>>of course that doesn't solve the general problem of which this is a
>>much-reduced example.
>>
>>If I use timezone US/Central, I get the same (bad) plot.
>>
>>import matplotlib.pyplot as plt
>>import datetime
>>import pytz
>>pacific = pytz.timezone("US/Pacific")
>>fig = plt.figure()
>>plt.plot([datetime.datetime(2014, 10, 7, 8, 30, tzinfo=pacific),
>>          datetime.datetime(2014, 10, 7, 9, 30, tzinfo=pacific)],
>>         [0,1], marker="o", color="green")
>>fig.autofmt_xdate()
>>plt.show()
>>
>>Does anybody know why this shift is occurring?  Is Matplotlib
>>confused about what timezone to use in labeling the axis?  How
>>would I tell it what timezone to use (preferably explicitly in
>>the code, not in matplotlibrc)?
[snip]
>
> I know that your problem is that all your times are in UTC, even
> though you do not want this.  I had this too.  I forget what I did.

Actually, UTC is very helpful in this project, which has to
deal with timestamped data from various timezones.  After I finally
stumbled upon datetime's astimezone() method, things seemed to be
going smoothly . . .

> I do not know if this solution from stackoverflow.com will work for
> you -- it is definitely different from what I did, but that does
> not in any way make it wrong.  Try and see?  and report back?
>
> http://stackoverflow.com/questions/4485607/matplotlib-plot-date-keeping-times-in-utc-even-with-custom-timezone

Thanks for the pointer.  I'll report back.


-- 
To email me, substitute nowhere->runbox, invalid->com.

[toc] | [prev] | [next] | [standalone]

#93308

On Tue, Jun 30, 2015 at 10:56 AM, Peter Pearson
<pkpearson@nowhere.invalid> wrote:
> The following code produces a plot with a line running from (9:30, 0) to
> (10:30, 1), not from (8:30, 0) to (9:30, 1) as I desire.
>
> pacific = pytz.timezone("US/Pacific")
> plt.plot([datetime.datetime(2014, 10, 7, 8, 30, tzinfo=pacific),
>           datetime.datetime(2014, 10, 7, 9, 30, tzinfo=pacific)],
>          [0,1], marker="o", color="green")

Sounds to me like a bug in DST handling - in October 2014, Los Angeles
was on Pacific Daylight Time, which would give a one-hour offset if
matplotlib is handling things on the basis of Pacific Standard Time. I
don't know if that helps at all with figuring out a solution, though.

ChrisA

[toc] | [prev] | [next] | [standalone]

#93310

On Tue, 30 Jun 2015 12:11:31 +1000, Chris Angelico <rosuav@gmail.com> wrote:
> On Tue, Jun 30, 2015 at 10:56 AM, Peter Pearson
><pkpearson@nowhere.invalid> wrote:
>> The following code produces a plot with a line running from (9:30, 0) to
>> (10:30, 1), not from (8:30, 0) to (9:30, 1) as I desire.
>>
>> pacific = pytz.timezone("US/Pacific")
>> plt.plot([datetime.datetime(2014, 10, 7, 8, 30, tzinfo=pacific),
>>           datetime.datetime(2014, 10, 7, 9, 30, tzinfo=pacific)],
>>          [0,1], marker="o", color="green")
>
> Sounds to me like a bug in DST handling - in October 2014, Los Angeles
> was on Pacific Daylight Time, which would give a one-hour offset if
> matplotlib is handling things on the basis of Pacific Standard Time. I
> don't know if that helps at all with figuring out a solution, though.

Thanks, I think you're onto something.  Points in a non-daylight-saving
month get plotted correctly:

plt.plot([datetime.datetime(2014, 12, 7, 8, 30, tzinfo=pacific),
          datetime.datetime(2014, 12, 7, 9, 30, tzinfo=pacific)],
         [0,1], marker="o", color="green")

Time zones teem with sneaky software problems, and so does daylight-saving
time, so this problem might strain my brain.  Maybe it's going to turn
out that my expectations are unreasonable . . . as in, "Well, smarty pants,
how do you want the axis labelled when the abscissas straddle the
beginning of daylight-saving time?"  I'll research and digest.

-- 
To email me, substitute nowhere->runbox, invalid->com.

[toc] | [prev] | [next] | [standalone]

#93314

On Tue, Jun 30, 2015 at 2:49 PM, Peter Pearson
<pkpearson@nowhere.invalid> wrote:
> Time zones teem with sneaky software problems, and so does daylight-saving
> time, so this problem might strain my brain.  Maybe it's going to turn
> out that my expectations are unreasonable . . . as in, "Well, smarty pants,
> how do you want the axis labelled when the abscissas straddle the
> beginning of daylight-saving time?"  I'll research and digest.

That's entirely possible. Even more so if you go across some other
civil time change - if you look at the history of timezones in tzdata,
there's no end of messes as different places adopted standard time,
redefined standard time, and unified with someone else's standard
time. And some of that happened relatively recently.

UTC is much easier for this kind of thing. Especially if the
granularity of your data lets you ignore leap seconds.

ChrisA

[toc] | [prev] | [next] | [standalone]

#93341

On Tue, 30 Jun 2015 17:01:15 +1000, Chris Angelico <rosuav@gmail.com> wrote:
> On Tue, Jun 30, 2015 at 2:49 PM, Peter Pearson
><pkpearson@nowhere.invalid> wrote:
>> Time zones teem with sneaky software problems, and so does daylight-saving
>> time, so this problem might strain my brain.  Maybe it's going to turn
>> out that my expectations are unreasonable . . . as in, "Well, smarty pants,
>> how do you want the axis labelled when the abscissas straddle the
>> beginning of daylight-saving time?"  I'll research and digest.
>
> That's entirely possible. Even more so if you go across some other
> civil time change - if you look at the history of timezones in tzdata,
> there's no end of messes as different places adopted standard time,
> redefined standard time, and unified with someone else's standard
> time. And some of that happened relatively recently.
>
> UTC is much easier for this kind of thing. Especially if the
> granularity of your data lets you ignore leap seconds.

Hear, hear!  I'm an enthusiastic fan of UTC.  But I need to interact
with nontechnical people who will say, "Hey, I logged that widget at
9AM, why do you show it as 4PM?"  Another funny thing that happens in
the pure-UTC world is my software gets confused by the way Frank
abruptly shifts his logging schedule by an hour ... twice a year ...
when DST starts or stops.

I'm just glad I don't have to worry about the distinctions among 
UTC, GMT, TAI, and UT1.

-- 
To email me, substitute nowhere->runbox, invalid->com.

[toc] | [prev] | [next] | [standalone]

#93342

On Wed, Jul 1, 2015 at 2:42 AM, Peter Pearson <pkpearson@nowhere.invalid> wrote:
> I'm just glad I don't have to worry about the distinctions among
> UTC, GMT, TAI, and UT1.

Fortunately, that's often the case. GMT can be ignored, and the other
three differ by less seconds than most humans ever care about. If
you're scheduling a meeting, for instance, nobody's going to care if
your clocks differ by 36 seconds, which is as much as TAI and UTC will
differ in a few hours (there's a leap second scheduled for midnight at
the end of June 30th this year, and as my clock is now showing July,
it'll be happening soon). The difference between UTC and UT1 is
insignificant to virtually all humans, given that it's never more than
a single second; it's only high-precision calculations that ever need
concern themselves with that. So, yep! I share your gladness.
Distinctions exist but most of us don't have to worry about them.

ChrisA

[toc] | [prev] | [next] | [standalone]

#93358

On 30 Jun 2015 00:56:26 GMT, Peter Pearson <pkpearson@nowhere.invalid> wrote:
> The following code produces a plot with a line running from (9:30, 0) to
> (10:30, 1), not from (8:30, 0) to (9:30, 1) as I desire.
>
> If I use timezone None instead of pacific, the plot is as desired, but
> of course that doesn't solve the general problem of which this is a
> much-reduced example.
>
> If I use timezone US/Central, I get the same (bad) plot.
>
> import matplotlib.pyplot as plt
> import datetime
> import pytz
> pacific = pytz.timezone("US/Pacific")
> fig = plt.figure()
> plt.plot([datetime.datetime(2014, 10, 7, 8, 30, tzinfo=pacific),
>           datetime.datetime(2014, 10, 7, 9, 30, tzinfo=pacific)],
>          [0,1], marker="o", color="green")
> fig.autofmt_xdate()
> plt.show()
>
> Does anybody know why this shift is occurring?  Is Matplotlib
> confused about what timezone to use in labeling the axis?  How
> would I tell it what timezone to use (preferably explicitly in
> the code, not in matplotlibrc)?

Progress report:

I might be wrong in blaming the axis formatting.  It looks as if the
datetimes themselves are being created wrong.

https://docs.python.org/2/library/datetime.html gives an
example like this:

    >>> # Daylight Saving Time
    >>> dt1 = datetime(2006, 11, 21, 16, 30, tzinfo=gmt1)
    >>> dt1.dst()
    datetime.timedelta(0)
    >>> dt1.utcoffset()
    datetime.timedelta(0, 3600)
    >>> dt2 = datetime(2006, 6, 14, 13, 0, tzinfo=gmt1)
    >>> dt2.dst()
    datetime.timedelta(0, 3600)
    >>> dt2.utcoffset()
    datetime.timedelta(0, 7200)

... implying that adjustment for DST is made during the datetime constructor.
But look:

    >>> from datetime import datetime
    >>> import pytz
    >>> pacific = pytz.timezone("US/Pacific")
    >>> dt1 = datetime(2006, 11, 21, 16, 30, tzinfo=pacific) # no DST
    >>> dt2 = datetime(2006, 6, 14, 13, 0, tzinfo=pacific)   # yes DST
    >>> dt1.dst()
    datetime.timedelta(0)
    >>> dt2.dst()
    datetime.timedelta(0)
    >>> dt1.utcoffset()
    datetime.timedelta(-1, 57600)
    >>> dt2.utcoffset()
    datetime.timedelta(-1, 57600)

The dst() values are equal, and the utcoffset() values are equal, even
though one datetime is during DST and the other is not -- exactly the
opposite of the example.

The debugging tool pdb can't step into datetime.datetime(), so I'm
kinda stuck here.

-- 
To email me, substitute nowhere->runbox, invalid->com.

[toc] | [prev] | [next] | [standalone]

#93359

On Wed, Jul 1, 2015 at 3:50 PM, Peter Pearson <pkpearson@nowhere.invalid> wrote:
> But look:
>
>     >>> from datetime import datetime
>     >>> import pytz
>     >>> pacific = pytz.timezone("US/Pacific")
>     >>> dt1 = datetime(2006, 11, 21, 16, 30, tzinfo=pacific) # no DST
>     >>> dt2 = datetime(2006, 6, 14, 13, 0, tzinfo=pacific)   # yes DST
>     >>> dt1.dst()
>     datetime.timedelta(0)
>     >>> dt2.dst()
>     datetime.timedelta(0)
>     >>> dt1.utcoffset()
>     datetime.timedelta(-1, 57600)
>     >>> dt2.utcoffset()
>     datetime.timedelta(-1, 57600)
>
> The dst() values are equal, and the utcoffset() values are equal, even
> though one datetime is during DST and the other is not -- exactly the
> opposite of the example.

Just to confirm, they are still showing the times as 16:30 and 13:00, right?

Interestingly, when I tried this (pytz version 2015.4, Python 2.7.9,
Debian Jessie), I saw utcoffset() showing (-1, 58020) for both. That
seems... odd. And I can't fault your dates - those definitely ought to
be easily inside and easily outside the DST boundaries. When I try
those dates in an unrelated time converter, they do show seven- and
eight- hour offsets to UTC. Maybe we're both misunderstanding the
meaning of utcoffset()?

ChrisA

[toc] | [prev] | [next] | [standalone]

#93379 — Datetime timezone trouble (was: Matplotlib X-axis timezone trouble)

On Wed, 1 Jul 2015 17:15:38 +1000, Chris Angelico <rosuav@gmail.com> wrote:
>
> Interestingly, when I tried this (pytz version 2015.4, Python 2.7.9,
> Debian Jessie), I saw utcoffset() showing (-1, 58020) for both. That
> seems... odd. And I can't fault your dates - those definitely ought to
> be easily inside and easily outside the DST boundaries. When I try
> those dates in an unrelated time converter, they do show seven- and
> eight- hour offsets to UTC. Maybe we're both misunderstanding the
> meaning of utcoffset()?

Here's a very simple demonstration that either something is wrong
or I don't understand how datetime and tzinfo are supposed to work:

$ python
Python 2.7.3 (default, Mar 13 2014, 11:03:55) 
>>> from pytz import timezone
>>> from datetime import datetime
>>> pacific = timezone("US/Pacific")
>>> print(datetime(2014, 7, 7, 12, tzinfo=pacific))
2014-07-07 12:00:00-08:00
>>> print(datetime(2014, 1, 7, 12, tzinfo=pacific))
2014-01-07 12:00:00-08:00
>>> 

The "-08:00" is appropriate in the second (January) case, but the
first case is in July, and should have "-07:00".

-- 
To email me, substitute nowhere->runbox, invalid->com.

[toc] | [prev] | [next] | [standalone]

#93380 — Re: Datetime timezone trouble (was: Matplotlib X-axis timezone trouble)

On Wed, Jul 1, 2015 at 10:36 AM, Peter Pearson
<pkpearson@nowhere.invalid> wrote:
> On Wed, 1 Jul 2015 17:15:38 +1000, Chris Angelico <rosuav@gmail.com> wrote:
>>
>> Interestingly, when I tried this (pytz version 2015.4, Python 2.7.9,
>> Debian Jessie), I saw utcoffset() showing (-1, 58020) for both. That
>> seems... odd. And I can't fault your dates - those definitely ought to
>> be easily inside and easily outside the DST boundaries. When I try
>> those dates in an unrelated time converter, they do show seven- and
>> eight- hour offsets to UTC. Maybe we're both misunderstanding the
>> meaning of utcoffset()?
>
> Here's a very simple demonstration that either something is wrong
> or I don't understand how datetime and tzinfo are supposed to work:
>
> $ python
> Python 2.7.3 (default, Mar 13 2014, 11:03:55)
>>>> from pytz import timezone
>>>> from datetime import datetime
>>>> pacific = timezone("US/Pacific")
>>>> print(datetime(2014, 7, 7, 12, tzinfo=pacific))
> 2014-07-07 12:00:00-08:00
>>>> print(datetime(2014, 1, 7, 12, tzinfo=pacific))
> 2014-01-07 12:00:00-08:00
>>>>
>
> The "-08:00" is appropriate in the second (January) case, but the
> first case is in July, and should have "-07:00".

Use this instead:

>>> print(pacific.localize(datetime(2014, 7, 7, 12)))
2014-07-07 12:00:00-07:00

See http://pytz.sourceforge.net/#localized-times-and-date-arithmetic

[toc] | [prev] | [next] | [standalone]

#93383 — Re: Datetime timezone trouble (was: Matplotlib X-axis timezone trouble)

On Wed, 1 Jul 2015 10:55:02 -0600, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Wed, Jul 1, 2015 at 10:36 AM, Peter Pearson [wrote]:
[snip]
>> Here's a very simple demonstration that either something is wrong
>> or I don't understand how datetime and tzinfo are supposed to work:
>>
>> $ python
>> Python 2.7.3 (default, Mar 13 2014, 11:03:55)
>>>>> from pytz import timezone
>>>>> from datetime import datetime
>>>>> pacific = timezone("US/Pacific")
>>>>> print(datetime(2014, 7, 7, 12, tzinfo=pacific))
>> 2014-07-07 12:00:00-08:00
>>>>> print(datetime(2014, 1, 7, 12, tzinfo=pacific))
>> 2014-01-07 12:00:00-08:00
>>>>>
>>
>> The "-08:00" is appropriate in the second (January) case, but the
>> first case is in July, and should have "-07:00".
>
> Use this instead:
>
>>>> print(pacific.localize(datetime(2014, 7, 7, 12)))
> 2014-07-07 12:00:00-07:00
>
> See http://pytz.sourceforge.net/#localized-times-and-date-arithmetic

Excellent.  Thank you.

To summarize, for any similarly afflicted person who finds this thread:

 - http://pytz.sourceforge.net/#localized-times-and-date-arithmetic says:

    Unfortunately using the tzinfo argument of the standard datetime
    constructors ‘’does not work’’ with pytz for many timezones.

    It is safe for timezones without daylight saving transitions though,
    such as UTC:

 - PEP 0431 says (approximately) that datetime doesn't work as well
   as we might like with DST, but will be slow to change.

 - The "localize" function is pytz's way of working around this
   shortcoming of datetime's


-- 
To email me, substitute nowhere->runbox, invalid->com.

[toc] | [prev] | [next] | [standalone]

#93381 — Re: Datetime timezone trouble (was: Matplotlib X-axis timezone trouble)

On Thu, Jul 2, 2015 at 2:36 AM, Peter Pearson <pkpearson@nowhere.invalid> wrote:
> On Wed, 1 Jul 2015 17:15:38 +1000, Chris Angelico <rosuav@gmail.com> wrote:
>>
>> Interestingly, when I tried this (pytz version 2015.4, Python 2.7.9,
>> Debian Jessie), I saw utcoffset() showing (-1, 58020) for both. That
>> seems... odd. And I can't fault your dates - those definitely ought to
>> be easily inside and easily outside the DST boundaries. When I try
>> those dates in an unrelated time converter, they do show seven- and
>> eight- hour offsets to UTC. Maybe we're both misunderstanding the
>> meaning of utcoffset()?
>
> Here's a very simple demonstration that either something is wrong
> or I don't understand how datetime and tzinfo are supposed to work:
>
> $ python
> Python 2.7.3 (default, Mar 13 2014, 11:03:55)
>>>> from pytz import timezone
>>>> from datetime import datetime
>>>> pacific = timezone("US/Pacific")
>>>> print(datetime(2014, 7, 7, 12, tzinfo=pacific))
> 2014-07-07 12:00:00-08:00
>>>> print(datetime(2014, 1, 7, 12, tzinfo=pacific))
> 2014-01-07 12:00:00-08:00
>>>>
>
> The "-08:00" is appropriate in the second (January) case, but the
> first case is in July, and should have "-07:00".

Interesting. I poked around with the docstring for pytz.timezone and
replicated it more exactly, and this appears to work:

$ python
Python 2.7.9 (default, Mar  1 2015, 12:57:24)
[GCC 4.9.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from pytz import timezone
>>> from datetime import datetime
>>> pacific = timezone("US/Pacific")
>>> utc = timezone("UTC")
>>> print(datetime(2014, 7, 7, 12, tzinfo=utc).astimezone(pacific))
2014-07-07 05:00:00-07:00
>>> print(datetime(2014, 1, 7, 12, tzinfo=utc).astimezone(pacific))
2014-01-07 04:00:00-08:00

Clearly I do not understand what's going on here.

ChrisA

[toc] | [prev] | [next] | [standalone]

#93479

Peter Pearson <pkpearson@nowhere.invalid> writes:

> The following code produces a plot with a line running from (9:30, 0) to
> (10:30, 1), not from (8:30, 0) to (9:30, 1) as I desire.
>
> If I use timezone None instead of pacific, the plot is as desired, but
> of course that doesn't solve the general problem of which this is a
> much-reduced example.
>
> If I use timezone US/Central, I get the same (bad) plot.
>
> import matplotlib.pyplot as plt
> import datetime
> import pytz
> pacific = pytz.timezone("US/Pacific")
> fig = plt.figure()
> plt.plot([datetime.datetime(2014, 10, 7, 8, 30, tzinfo=pacific),
>           datetime.datetime(2014, 10, 7, 9, 30, tzinfo=pacific)],
>          [0,1], marker="o", color="green")
> fig.autofmt_xdate()
> plt.show()
>
> Does anybody know why this shift is occurring?  Is Matplotlib
> confused about what timezone to use in labeling the axis?  How
> would I tell it what timezone to use (preferably explicitly in
> the code, not in matplotlibrc)?
>

Your pytz usage is incorrect.

Don't pass a pytz tzinfo object to the datetime construtor directly, use
`.localize()` method instead. Read the note at the very beginning of
pytz docs http://pytz.sourceforge.net/

[toc] | [prev] | [next] | [standalone]

#93491 — Re: Matplotlib X-axis timezone trouble [SOLVED]

On Sat, 04 Jul 2015 07:29:45 +0300, Akira Li <4kir4.1i@gmail.com> wrote:
> Peter Pearson <pkpearson@nowhere.invalid> writes:
>
>> The following code produces a plot with a line running from (9:30, 0) to
>> (10:30, 1), not from (8:30, 0) to (9:30, 1) as I desire.
>>
>> If I use timezone None instead of pacific, the plot is as desired, but
>> of course that doesn't solve the general problem of which this is a
>> much-reduced example.
>>
>> If I use timezone US/Central, I get the same (bad) plot.
>>
>> import matplotlib.pyplot as plt
>> import datetime
>> import pytz
>> pacific = pytz.timezone("US/Pacific")
>> fig = plt.figure()
>> plt.plot([datetime.datetime(2014, 10, 7, 8, 30, tzinfo=pacific),
>>           datetime.datetime(2014, 10, 7, 9, 30, tzinfo=pacific)],
>>          [0,1], marker="o", color="green")
>> fig.autofmt_xdate()
>> plt.show()
>>
>> Does anybody know why this shift is occurring?  Is Matplotlib
>> confused about what timezone to use in labeling the axis?  How
>> would I tell it what timezone to use (preferably explicitly in
>> the code, not in matplotlibrc)?
>>
>
> Your pytz usage is incorrect.
>
> Don't pass a pytz tzinfo object to the datetime construtor directly, use
> `.localize()` method instead. Read the note at the very beginning of
> pytz docs http://pytz.sourceforge.net/

Exactly.  Thank you.

For newcomers, the denouement of this thread is this:

 * Matplotlib had nothing to do with this problem, it was correctly
   displaying bad datetime.datetime values.

 * Python's datetime.datetime(..., tzinfo=timezone) is unreliable if
   timezone has daylight-saving time.

 * pytz's creators provide the localize() method specifically to
   remedy this problem.  If you want to create a datetime object
   that has a timezone that might have daylight-saving time,
   use localize().

-- 
To email me, substitute nowhere->runbox, invalid->com.

[toc] | [prev] | [next] | [standalone]

#93598

On Tue, 30 Jun 2015 00:56:26 +0000, Peter Pearson wrote:

> If I use timezone US/Central, I get the same (bad) plot.

Perhaps this can help?:
http://stackoverflow.com/questions/1301493/setting-timezone-in-python


 /Grrr
-- 
          ___                  ___
 (\_--_/)  | _ ._    _|_|_  _   |o _  _ ._
 ( 9  9 )  |(_)| |\/  |_| |(/_  ||(_|(/_|
 stripes are forever - as overripe ferrets

[toc] | [prev] | [next] | [standalone]

#93649

On Thu, 09 Jul 2015 19:50:33 GMT, Tony the Tiger <tony@tiger.invalid> wrote:
> On Tue, 30 Jun 2015 00:56:26 +0000, Peter Pearson wrote:
>
>> If I use timezone US/Central, I get the same (bad) plot.
>
> Perhaps this can help?:
> http://stackoverflow.com/questions/1301493/setting-timezone-in-python

Yes, thanks.  As I summarized (in greater detail) elsewhere on this
thread, Matplotlib was entirely innocent, and was correctly labeling
erroneous datetime objects.  My real problem was that datetime.datetime()
malfunctions when its tzinfo parameter is a timezone with daylight
saving time.  The practical solution is to use pytz.localize().

-- 
To email me, substitute nowhere->runbox, invalid->com.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web