nc-time-axis
nc-time-axis copied to clipboard
SciTools
Add an example of a(n horribly) wrong plot when NOT using nc-time-axis
📚 Documentation
This is a nice and useful extension of cftime and matplolib!
We spent some time this afternoon with @oliviermarti trying to understand why a time series based on data using a noleap calendar was plotted (seemingly) correctly with default settings, but was shifted (30 years in our case) when we tried to format the tick labels with set_major_formatter, following the appropriate examples in the matplotlib gallery. We were lucky to spot this, because matplotlib was not generating any error! I guess matplotlib was happy enough to handle cftime data as if it was regular datetime data
The question now is how to tell our climate data users that they (or most likely their unsuspecting interns) will get horribly wrong plots if they rely on matplolib defaults...
What could work would be to display side by side a matplotlib plot using some dummy data with a cftime+noleap time axis, and a correct plot using nc-time-axis, if somebody can come up with a simple example (I'm not volunteering!)
Thanks for raising this @jypeter -- sorry this tripped you and @oliviermarti up! I'm optimistic there might something that could be done in matplotlib to address this (i.e. it would be great if matplotlib could raise an error for an unrecognized date type rather than display erroneous values), so we'll see what happens there.
Well, it's certainly not nc-time-axis' fault!
We don't know how long it will take for a fix to be added to matplotlib, and then when we will use this updated matplotlib in our environments, so an example of what happens when people don't use nc-time-axis would be very useful
Anyway, I think examples of what can silently go dreadfully wrong are very good teaching examples, and we have to remind our students (and not just them) to pay attention to their code and the resulting output!
Just a few days ago, some of our students were talking about how neat this hyped chatgpt thingy was for generating code. I don't want them to go this way... :-(
We have here an opportunity to kill several ~~birds~~bugs with one stone:
- avoid calendar-related display bugs
- remind people to check simple things in their plot (like is what is displayed on an axis consistent with the data?)
- advertise
nc-time-axis
I may have misunderstood but, from the discussion at https://github.com/Unidata/cftime/issues/303, it looks like you didn't know to use nc-time-axis. If a user does not know to use this package, then they wouldn't look in this package's docs for how not to do it.
You are right, most people unfortunately don't know about nc-time-axis (and possible non-standard calendars related problems)!
It took @oliviermarti and I some time to identify the problem and try to find a(n existing) fix. Finding the package with Google can be done, but we would like to warn our lab users (and the IPSL modellers) and tell them how to fix the problem
I think the best way to do it would be to send a link to an example in nc-time-axis documentation (with simple dummy data using non-standard calendars) showing them what happens when they plot data with/without nc-time-axis (and with/without a date formatter)