2.4.3.13: end time in the past... why?

Hi guys,

I just started a sequence after updating to 2.4.13. My final target is set to end at 5:00 AM. I started the sequence at 4:57PM and got this:

I presume that is because 5:00 AM is 12 hrs and 3 minutes in the future so SGP interpreted it as being in the past. As our nights get longer and I start my sequences earlier and let them finish later, this will become a problem every night! Even if I wait until astronomical twilight to start the sequence, it will still be more than 12 hours before my last target ends.

What can we do about this?

Although not necessarily a real solution, could we at least get a third option on the message box to treat the date as being in the future? (though I preferred the old behavior and would be more in favor of a solution that does not involve an interactive dialog box)

Thanks,
Andy

sg_logfile_20151103165551.zip (7.9 KB)

This will be a problem for me to, for the same reasons Andy says.
Recognizing I may not be understanding things correctly, this is also why I
asked about using a 24 hour clock (military time). If Andy has his end
time as 05:00, and the time he started the sequence is 16:57, would SGP
interpret the end time as being in the future and start the sequence
without alerts?

This would also mean that Chris Mads could start his sequence at 06:00
before he goes to work and would honor his end time of 05:00 the NEXT
morning.

We can always add dates back…

I don’t understand how this can be true… We removed dates as requested so we have to infer them. The rule system is simple. The only thing we can do is:

  • Add dates back so users can be explicit about exactly when they want things to happen… no questions.
  • Create a rule system that infers dates (the only way to do this is say that some amount of hours before “now” is in the past and some number of hours from “now” is in the future. Right now it’s an even 12 / 12 split. This could be shifted to be 14 / 10 or something, but there needs to be a set of inferred rules if dates are not present.

None of this has anything to do with 24 hour time… time is time, 24 hour time is how some people express it and nothing else.

Also… the “why?” part is here:

Each solution irritates a different set of people.

I’m pretty sure nobody liked the dates, hopefully we don’t have to go back to that!

I don’t have the full picture of what led to the recent change in 2.4.3.13, but for me personally I thought it was working just fine with all times in the future. If I wanted to start a sequence in the middle of the night with some of the targets having passed, I could just un-check the those targets. Clearing the checkboxes is a lot easier than going in to each target’s settings and changing the times.

Andy

Maybe, but it’s completely non-intuitive to have a target that has an end time of 21:00 start up because you started your sequence at 21:15.

Yeah like I said I’m not fully understanding this and I bow to the wisdom
of the benevolent overlords :slight_smile:

My thinking (incorrectly) was that SGP’s “timer” is always looking ahead
up to 24hrs. So even if a sequence is started at 06:00 the counting will
always be increasing, until it resets at 00:00 and would then honor the end
time of 05:00. I just realized that perhaps that only works for the global
end time and not each specific target end time.

I trust you more than I trust myself so I’ll say no more.

Ok, here’s an idea. Suppose we define a day boundary as end of astronomical twilight. “Today” begins at the day boundary. Dates always mean “today”, and never mean any other date on the other side of a day boundary.

Your 21:15 example:

“now” is 21:15 on 11/3. the start of today is 4:45 AM 11/3. today ends at 4:45 AM 11/4.
21:00 “today” is 21:00 on 11/3. it is in the past.

My sequence:

“now” is 4:57 PM on 11/3. Target end time is 5AM “today” = 5AM 11/4. it is in the future.

Early bird Chris:

Now is 6AM 11/3, Today starts at 4:45 AM 11/3. Target start time is 8PM “today” = 8PM 11/3, it is in the future.

All cases covered… right?

Andy

Maybe. It’s a good idea and I’d like to try it. The initial problem is that astronomical twilight is dependent on geographic position. It can be determined with an ASCOM mount (assuming it is set properly) . Then, of course, there is the subset of people that use cameras and filter wheel and never connect a mount. Then this becomes another manual entry. I also don’t know how this would work in extreme northern or southern latitudes.

I think it could still work with any arbitrary day boundary, like say, 9AM or noon. People who want to cover the early bird case might have to manually enter their “today starts at” setting (I know how much you hate settings!)

ok, another idea: the day boundary could be the latest end time of any target. Scan the targets, find the latest end time and use that value as the day boundary. Not sure what to do if if no targets have an end time though.

Andy

Sounds like there might be something here…

I think this only matters if there is at least one start time, but no end times right?

Actually @Andy… thinking about this… If we are ever going to move toward different expressions of end time like LST or altitude, maybe we should bite the bullet and figure out the least painful way to geographically locate users. We will need to find this data for a user one way or the other. I just want to avoid a “solution” that causes endless support requests titled “target does not start / end when I told it to”

After thinking about it more, the “last end time” boundary seems pretty bullet-proof to me, and does not require location information.

The only holes I can think of are events with start times but no end times.

Perhaps in the case where there are start times but no end times, make the (global) sequence end time setting mandatory? Or perhaps always make it mandatory? You could initialize it with a reasonable very permissive default, like 9AM.

Even if you know the local astronomical twilight, I think there will still be people unhappy if SGP always makes that the day boundary. For instance, somebody who wants to image a bit after astro. twilight (setting their end time after A.T.), or the real early bird who wants to start their sequence for the coming evening but clicks start before astro. twilight. Those cases can be avoided with a “day starts at” setting, but to really avoid adding a new setting, using sequence end time (by making it mandatory) might be a good solution.

Andy

Bear in mind that for some of us if you chose astronomical twilight there will be period where it will never get dark, A couple of months for me in the UK,

Chris

OK – two more cents.

The underlying issue is that “time counting” resets at midnight. The only unambiguous way to define start and end times is to associate them with a date. However, the associated start and end dates can be calculated by SGP and do not have to be entered by the imager.

When a sequence is started, SGP would need to parse the start and end times of each target and internally assign a start and end date to each of those times. Then enforce target start and target end using the full date + time value.

  1. If the target start time is equal to or greater than the sequence start time, the target start time is associated with the current date.

  2. If the target start time is less than the sequence start time, the associated target start date is the next day.

  3. If the target end time is less than the target start time, the target end date is the next day.

  4. If the target end time is greater than target start time, the target end date is the same day.

Charlie

Perhaps I’m being a bit simplistic but it seems to me there are three cases for each target.

  1. No start time and no end time : Run always
  2. Both start time and end time : Run if current time is between start and end
  3. Either start or end time given : Assume the other time is 12 noon and apply case 2.

Using 12 noon as the missing time is more definitive and very easy to explain.

The one situation this idea does not cover is if a target is say 7PM to 7AM and a sequence is started at 6AM and the user really means for it to be run the next night. If this situation is considered important, there could be some UI element that allow the user to specify “Wait for start time”. This UI element could be specified with the limits or perhaps SGP could detect the situation when a sequence is started and query the user.

For the next version of SGP, start and end limits by altitude is planned. To do this calculation, SGP will need to know the site latitude and longitude. Knowing this information would allow a calculation of astronomical twilight start and end. These would be useful times to use for start/end as well as fixed times.

One last thought, when SGP allows altitude limits it would be useful to allow both time and altitude start/end limits for each target. In this case, the most restricted limit should take precedence.

@chasmiller46, you are really on to the perfect solution here, IMHO. I started this rehash of this issue a week ago because the behavior of running the sequence changed depending on when you started the sequence, or even produced a strange sequence. If you started it before the start time of the first target, it would run one way, in my case #1, #2, #1, #3, which of course was not what I intended or would be expected. The reason it returned to #1 after finishing #2 is that it reevaluated the end time of #1 and now decided that it was in the future, which it was 2 hours ago, but should now be in the past when #3 should start, quite inconsistent, and the target had more frames to process, so it started it again.

Another common scenario for me is starting the sequence after 1 or more targets have already run and still have some additional frames to take, but finished because the end time came before finishing all frames. If I don’t explicitly uncheck the earlier finished targets, it would restart with them. It should still know that they have finished and those end times are now in the past,

A key element to add to your rules is:
The starting date should always be set to make target #1 start at a future date/time, unless that would cause the whole sequence to start more that 24 hours from now. The 24 hours may need to be shortened some. Then the sequence can be started any time during the evening and produce the same results for that period of time.

And if a necessary start or end time is not specified that these rules require, SGP could just make a reasonable assumption for the missing time.

And for me, reverting to using dates would be a disaster. They set of rules should work great for everyone.

@jmacon : I believe rule #1 and #2 already force that to happen. Unless I am missing something special in the way you want to do starts and ends.

One extra point about targets with missing start and/or end times:

SGP would calculate a default target start time as the current date - time; that is, the time the sequence was started.

SGP would calculate a default end date - time that was 12 hours past the start date - time. If that default doesn’t work, then enter the end time you need.

Charlie

Calculating dates is not necessary. By definition the end time is past the start time. If that happens to roll over to another day that is fine. If you have both start and end times, the time interval is well defined. The real question is how to handle a start time without an end time or an end time without an start time. I proposed using 12 noon for the missing time because it is very simple to calculate and explain to users. Also, for astronomers a more practical “day” is noon to noon rather than midnight to midnight. The method that chasmiller46 proposes is interesting but basing the start time on the current time is problematic in that the results are time of day dependent. Using a fixed time like 12 noon results in a consistent meaning.