Reduce AutoDateFormatter precision when possible #4809

matthijskooijman · 2015-07-28T16:48:01Z

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: #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:16Z

Note that this pullrequest has not been tested as-is, since I don't have time right now to set up a full matplotlib build from git. I did test the changes backported into 1.4.3, which works as expected.

WeatherGod · 2015-07-28T19:11:54Z

lib/matplotlib/dates.py

+           1.0                    : '%b %d %Y',
+           1. / HOURS_PER_DAY     : '%H:%M',
+           1. / SEC_PER_DAY       : '%H:%M:%S',
+           1. / MUSECONDS_PER_DAY : '%H:%M:%S.%f'


This part is a doc-string, so perhaps it doesn't make sense to use the global variables here?

I would say it makes the documentation more clear like this? Also, expanding MUSECONDS_PER_DAY would result in 1. / (24 * 60 * 60 * 1000000), which struck me as overly complicated. But I'm happy to change back to numbers if you think that would be better?

fair enough. I'll let others weigh in with their preference.

I think the globals as much more readable.

- 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

mdboom · 2015-12-14T18:31:21Z

Would it make sense to just combine this with #5445, @tacaswell?

- 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

tacaswell added the status: needs review label Jul 28, 2015

WeatherGod reviewed Jul 28, 2015
View reviewed changes

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

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

azjps mentioned this pull request Jul 29, 2015

Microsecond support in DatetimeTickFormatter bokeh/bokeh#2632

Merged

Intheelement mentioned this pull request 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 pull request Nov 8, 2015

DFLT: change formats for AutoDateFormatter #5445

Closed

tacaswell self-assigned this Nov 8, 2015

tacaswell closed this 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

Reduce AutoDateFormatter precision when possible #4809

Reduce AutoDateFormatter precision when possible #4809

matthijskooijman commented Jul 28, 2015

matthijskooijman commented Jul 28, 2015

WeatherGod Jul 28, 2015

matthijskooijman Jul 29, 2015

WeatherGod Jul 29, 2015

tacaswell Jul 29, 2015

mdboom commented Dec 14, 2015

Reduce AutoDateFormatter precision when possible #4809

Reduce AutoDateFormatter precision when possible #4809

Conversation

matthijskooijman commented Jul 28, 2015

matthijskooijman commented Jul 28, 2015

WeatherGod Jul 28, 2015

Choose a reason for hiding this comment

matthijskooijman Jul 29, 2015

Choose a reason for hiding this comment

WeatherGod Jul 29, 2015

Choose a reason for hiding this comment

tacaswell Jul 29, 2015

Choose a reason for hiding this comment

mdboom commented Dec 14, 2015