Fix #110: Ensure spectrogram plotting correctly handles non-UTC time scales#144
Conversation
36a89e4 to
7da7edd
Compare
|
This is not specific to this PR. I'm posting this to all open PRs. Please be aware of the update to our AI usage policy, specifically on the disclosure of and acceptable uses of AI. |
samaloney
left a comment
There was a problem hiding this comment.
Thanks for the RP but I'm not sure defaulting to UTC is the best option. What if someone wants to plot in tt scale, it would be better to convert to the existing scale if one exists.
Should be able to use or follow similar approach to astroy's time_support
|
Thanks a lot for your response. @samaloney I am currently working on a way to solve the issue by not defaulting to UTC but i am stuck and having a doubt regarding the scales. For mixed time scales on the same axes, should the first plotted scale define the axis scale for the plots? |
7da7edd to
5a18b2e
Compare
… from old matplotlib
samaloney
left a comment
There was a problem hiding this comment.
Great I think this is almost ready just a small tidy up of the imports and should be good to go.
* Resolve conflicts with merged PR #144 and simplify axis converter
PR Description
Fixes an issue where plotting data with different time scales i.e. 'tt' and 'utc' would result in time offsets because
GenericSpectrogramplotting was using the raw time scale components directly via.datetime. Corrects the plotting logic to always convert to UTC first.Closes #110
What changed
radiospectra/mixins.pyto ensureself.timesis converted to UTC before generatingdatetimeobjects for plotting._times_utc_datetimeto handle the conversion if supported by the time object.@samaloney, Let me know your thoughts on this!!