AutoDateFormatter shows too much precision #4808

matthijskooijman · 2015-07-28T14:40:40Z

When trying to plot some date-based values, I noticed that the default labels show too much precision. I was trying to plot some data points over a minutes to hours interval, and the default plot kept showing times using a micro-second precision. Given that the major ticks were minutes apart, this seems overkill to me (and the extra digits quickly clutter the display, making the labels overlap).

Diving into the code, it seems the default "scaled" member of the
AutoDateFormatter, which determines what formats to use when, can be
improved. Currently, it:

Uses microsecond precision when the ticks are minutes or less apart.
Uses second precision when the ticks are hours apart
Uses day-precision, month or year precision when the ticks are days
or more apart (these are fine, so I lumped them together).

I think it should be like this:

Use microsecond precision when the ticks less than a second apart
Use second precision when the ticks are seconds apart
Use minute precision when the ticks are minutes or hours apart
Use day-precision, month or year precision when the ticks are days
or more apart (unchanged).

Note that there is no point in displaying only the hour when the ticks
are hours apart, since then it won't be immediately clear that a time is
being displayed. Adding the (technically superfluous) :00 for the
minutes should prevent this, which is why the minute precision should
also be used when the ticks are hours apart.

The above would be implemented by the following change (documentation
not updated yet):

@@ -563,8 +573,9 @@
         self.scaled = {DAYS_PER_YEAR: '%Y',
                        DAYS_PER_MONTH: '%b %Y',
                        1.0: '%b %d %Y',
-                       1. / HOURS_PER_DAY: '%H:%M:%S',
-                       1. / (MINUTES_PER_DAY): '%H:%M:%S.%f'}
+                       1. / HOURS_PER_DAY: '%H:%M',
+                       1. / SEC_PER_DAY: '%H:%M:%S',
+                       1. / MUSECONDS_PER_DAY: '%H:%M:%S.%f'}

     def __call__(self, x, pos=None):
         locator_unit_scale = float(self._locator._get_unit())

Does this sound reasonable?

The text was updated successfully, but these errors were encountered:

WeatherGod · 2015-07-28T14:52:22Z

This might be perfect for the upcoming v2.0 style-change release, but I
wouldn't be against it being treated as a bugfix and put into 1.5 (to be
released soon). Could you put together a Pull Request with this change?
This way, we can see exactly how this looks as it would (hopefully) break
some unit tests.

On Tue, Jul 28, 2015 at 10:40 AM, Matthijs Kooijman <
[email protected]> wrote:

When trying to plot some date-based values, I noticed that the default
labels show too much precision. I was trying to plot some data points over
a minutes to hours interval, and the default plot kept showing times using
a micro-second precision. Given that the major ticks were minutes apart,
this seems overkill to me (and the extra digits quickly clutter the
display, making the labels overlap).

Diving into the code, it seems the default "scaled" member of the
AutoDateFormatter, which determines what formats to use when, can be
improved. Currently, it:

Uses microsecond precision when the ticks are minutes or less apart.

Uses second precision when the ticks are hours apart

Uses day-precision, month or year precision when the ticks are days
or more apart (these are fine, so I lumped them together).

I think it should be like this:

Use microsecond precision when the ticks less than a second apart

Use second precision when the ticks are seconds apart

Use minute precision when the ticks are minutes or hours apart

Use day-precision, month or year precision when the ticks are days
or more apart (unchanged).

Note that there is no point in displaying only the hour when the ticks
are hours apart, since then it won't be immediately clear that a time is
being displayed. Adding the (technically superfluous) :00 for the
minutes should prevent this, which is why the minute precision should
also be used when the ticks are hours apart.

The above would be implemented by the following change (documentation
not updated yet):

@@ -563,8 +573,9 @@
self.scaled = {DAYS_PER_YEAR: '%Y',
DAYS_PER_MONTH: '%b %Y',
1.0: '%b %d %Y',
                  1. / HOURS_PER_DAY: '%H:%M:%S',
                  1. / (MINUTES_PER_DAY): '%H:%M:%S.%f'}
                  1. / HOURS_PER_DAY: '%H:%M',
                  1. / SEC_PER_DAY: '%H:%M:%S',
                  1. / MUSECONDS_PER_DAY: '%H:%M:%S.%f'}
def call(self, x, pos=None):
locator_unit_scale = float(self._locator._get_unit())
Does this sound reasonable?

—
Reply to this email directly or view it on GitHub
#4808.

Previously, the AutoDateFormatter would choose a format with second or microsecond precision, even when the ticks were significantly coarser than that. The resulting extra precision looks weird and can clutter the display (especially with the long microsecond display). This commit changes the default scale to format dictionary, which now works as follows: - Use microsecond precision when the ticks are less than a second apart - Use second precision when the ticks are seconds apart - Use minute precision when the ticks are minutes or hours apart - Use day-precision, month or year precision when the ticks are days or more apart (unchanged). Note that there is no point in displaying only the hour when the ticks are hours apart, since then it won't be immediately clear that a time is being displayed. Adding the (technically superfluous) :00 for the minutes should make it immediately obvious that a time is being displayed, which is why the minute precision should also be used when the ticks are hours apart. While updating the documentation for this change, it was also changed to use symbolic constants instead of hardcoded numbers. This should make it more clear what the intention is. Closes: matplotlib#4808

matthijskooijman · 2015-07-28T16:49:58Z

Thanks for your reply, I created a PR just now.

- Use ISO complient formats by default - aded extra level of scale (seconds) - add rcparams for all of these strings closes matplotlib#4808 closes matplotlib#4809 closes matplotlib#5086

ahed87 · 2015-11-27T20:58:30Z

Hi,
a bit of hi-jack, but...

Quite some time ago I was making a plot with dates, and tried to get the axis to format milliseconds.
I could not get that working, there were some comments around that it was not possible, so I stopped trying, and made sure that it was only second resolution which became very coarse, but displaying the microseconds just added too many digits for readability.

Would it be possible to add milliseconds to the formatter, or at least the choise of digits in the formatter.
It's kind of a large step to go from seconds to microseconds,
I think it would be appreciated if milliseconds appeared before microseconds.

- Use ISO complient formats by default - aded extra level of scale (seconds) - add rcparams for all of these strings closes matplotlib#4808 closes matplotlib#4809 closes matplotlib#5086

matthijskooijman mentioned this issue Jul 28, 2015

Reduce AutoDateFormatter precision when possible #4809

Closed

tacaswell added the API: default changes label Jul 28, 2015

tacaswell added this to the Color overhaul milestone Jul 28, 2015

Intheelement mentioned this issue Sep 16, 2015

Default date format for axis formatting #5086

Closed

mdboom modified the milestones: Color overhaul, next major release (2.0) Oct 8, 2015

tacaswell mentioned this issue Nov 8, 2015

DFLT: change formats for AutoDateFormatter #5445

Closed

tacaswell self-assigned this Nov 8, 2015

tacaswell added the status: needs review label Nov 8, 2015

tacaswell closed this as completed in 1849626 Jan 8, 2016

tacaswell removed the status: needs review label Jan 8, 2016

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

AutoDateFormatter shows too much precision #4808

AutoDateFormatter shows too much precision #4808

matthijskooijman commented Jul 28, 2015

WeatherGod commented Jul 28, 2015

Uh oh!

matthijskooijman commented Jul 28, 2015

Uh oh!

ahed87 commented Nov 27, 2015

Uh oh!

Uh oh!

AutoDateFormatter shows too much precision #4808

AutoDateFormatter shows too much precision #4808

Comments

matthijskooijman commented Jul 28, 2015

WeatherGod commented Jul 28, 2015

Uh oh!

matthijskooijman commented Jul 28, 2015

Uh oh!

ahed87 commented Nov 27, 2015

Uh oh!