Stellarium
astrocal monthly graph: start today (or center on today) rather than start of year
No, this tool is working as designed - it showing a graph "Altitude vs. Time" for selected object at simulated year.
We have a strong reason not to do it! Some reasons for it can be found in the FAQ: https://github.com/Stellarium/stellarium/wiki/FAQ#Why_dont_you_implement
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Who would be interested in a calendar year's behaviour of an object? All other graphs can track current time, or provide a continuous sliding time window.
Also, what is so special about ONE year? Why can't the user study the behaviour of an object around the year's end? Or as from a starting date/time? Advancing one year causes a scale change. So why can't the user also select the range (number of months) across which the monthly elevation is plotted?
Maybe we don't even need the local time slider? Can't we just re-use the time selector? This would also get rid of having to slide from 23h to 0h just to study midnight behaviour.
So the current DATE would define the start of the graph (rather than Jan. 01) , and the current TIME would define the moment of the day (rather than the slider input). If possible, date/time changes should trigger a recalculation. And no, this was probably not the original intended behaviour. But this should simplify the UI.
And what I'm always struggling with is the "local time" slider. Does it take summertime into account? Why not use a UTC offset to make this more clear?
I agree that fixing it to a year makes little sense. Nature doesn't have a special time point at Jan 1. A smooth shift of the graph with current date seems more sensible to me that the sudden jump at a new year.
On Mon, 6 Oct 2025, 17:49 alex, @.***> wrote:
axd1967 left a comment (Stellarium/stellarium#4566) https://github.com/Stellarium/stellarium/issues/4566#issuecomment-3370784231
Who would be interested in a calendar year's behaviour of an object? All other graphs can track current time, or provide a continuous sliding time window.
Also, what is so special about ONE year? Why can't the user study the behaviour of an object around the year's end? Or as from a starting date/time? Advancing one year causes a scale change. So why can't the user also select the range (number of months) across which the monthly elevation is plotted?
Maybe we don't even need the local time slider? Can't we just re-use the time selector? This would also get rid of having to slide from 23h to 0h just to study midnight behaviour.
So the current DATE would define the start of the graph (rather than Jan. 01) , and the current TIME would define the moment of the day (rather than the slider input). If possible, date/time changes should trigger a recalculation. And no, this was probably not the original intended behaviour. But this should simplify the UI. image.png (view on web) https://github.com/user-attachments/assets/d0498cf9-2d41-47dc-9f4c-6488366af704
And what I'm always struggling with is the "local time" slider. Does it take summertime into account? Why not use a UTC offset to make this more clear?
— Reply to this email directly, view it on GitHub https://github.com/Stellarium/stellarium/issues/4566#issuecomment-3370784231, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABQU3MT2NTQCRXX5QVB7JEL3WI3KTAVCNFSM6AAAAACIMHQGX6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGNZQG44DIMRTGE . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Also, there would be no need for some "UTC offset" behaviour. The time is simply same as the time in the date/time selector; the user can choose (F6) what time is actually used. I think this is a far more elegant solution.
This tool is designed as a quick estimator for best time for observing of selected object in current year. So, the first obvious question - why the graph shouldn't be start at Jan 1? The second obvious question - why we should remove a tool for quick changing local time from the estimator?
This tool is designed as a quick estimator for best time for observing of selected object in current year.
If it's a tool for planning, then imagine it's December now. Does the user want to see what was happening in e.g. February of the current year? This wouldn't help planning, since it's long in the past. Thus, at the very least the current time should be in the middle. And if we're talking exclusively about planning, then it should be in the beginning of the graph.
The second obvious question - why we should remove a tool for quick changing local time from the estimator?
Not sure if we want to remove it, but indeed, since current date defines at least the year of the graph, then current time could be used as the daily local time for estimation.