BUG/Question: R-T Plots Start time shifts to previous 15 min interval

[carleyjmartin]

BUG

When plotting summary plots or range time plots using data read in that does not start at 15 minute intervals. The plot starts from the nearest previous 15 minute interval, and fills in with white spaces. I.e in the examples below I'm plotting data from 00:25 - 01:48 on 2nd March 2021 for Saskatoon beam 2.

Priority

• Minor - typo, incorrect naming, fails on specific uncommon situation
• Major - misrepresentation of data, failure in a common situation
• Urgent - failure in usage, large misrepresentation

Example of the bug

I've narrowed it down to these lines (412-421) in rtp.py

# setup some standard axis information
        # Upon request of Daniel Billet and others, I am rounding
        # the time down so the plotting x-axis will show the origin
        # time label
        # TODO: may need to be its own function
        rounded_down_start_time = x[0] -\
            timedelta(minutes=x[0].minute % 15,
                      seconds=x[0].second,
                      microseconds=x[0].microsecond)
        ax.set_xlim([rounded_down_start_time, x[-1]])

Attempts

As the end time works fine and ends with whatever time you give it, I tried to remove the % 15 from line 418. This results in the plot skipping to the nearest previous hour instead of 15 mins, making even more white space.

So then replaced the % 15 with % 1 and this now works as I wanted it to.

Potential Bug Location

see above and in the timeseries plot function at lines 671-674!

Potential Solution(s)

see above in attempts

rounded_down_start_time = x[0] -\
            timedelta(minutes=x[0].minute % 1,
                      seconds=x[0].second,
                      microseconds=x[0].microsecond)

Extra Notes

The notes next to this say:

# Upon request of Daniel Billet and others, I am rounding
 # the time down so the plotting x-axis will show the origin
 # time label

So if @billetd and others want to argue that this is a feature and not a bug, then go ahead. :P
If this is intended usage, is there a way I can override this as a default rather than me amending the source code in my version of pydarn? Obviously, when plotting an entire day it's hardly noticeable, but it's a large chunk from an hour or two of data.

[carleyjmartin]

This was originally discussed in PR: #20 before my time.
It seemed as though everyone was happy with the solution which forces the x-axis to have a tick at the start of the x-axis, but fills in any time before the 'start time' as white space.

My only issue is that we would be representing the time before the start time as 'no data' when there actually is data to go there, but also this is a very very minor issue, so if everyone is happy as is, I'm happy to wait on any responses and close this issue in a week or two.

I was developing this for use via our website, and was thinking that it would be easier to accept time in 15 min intervals rather than 1 min, so I can solve this on my end instead.

[mts299]

I think its something to look into, would you mind taking this on?

[carleyjmartin]

After discussing, these are the action points on this issue:

• Give a keyword option to/not to round off the start of the x-axis in time
• If the rounding off is done, fill in the time with the data and make sure the time period on the top of the plot if correct to the rounding.
• If option to round is chosen, make sure the start of the x-axis has a tick label (i.e. the rounding is the same as the tick frequency)

EDIT: In branch fix/start-time-shift there is now a keyword option to round so that the start of the x-axis has a tick label. This rounding is done automatically by detecting the tick interval being used and then rounding off to that value.
This means that for smaller amounts of data the white space is reduced. I'm not sure the filling in of data can be done easily without refactoring the entire code, and for now if a user inputs a time to start, then starting at that time is probably best, hence no amendments to the title or that second bullet point.
TODO: Requires the kwargs branch #169 to be merged then will amend for summary plots and we're good to go after that I think.