I wouldn’t suggest ‘time happens daily’ as things stand. It is a trigger and the piston doesn’t currently have any triggers, only conditions, so adding it would mean the piston would only run at 1am. Something similar using a time condition would do e.g. ‘time is after 3:30am’ (might as well use a later time and get DST fixed into the bargain).
For @angolandriver , the basic theory is to have your piston fired on Monday morning before 5:30am or sunrise. That should cause it to recalculate the values in your ‘time between’ statements and then wake up on the Monday schedule. It is a common trick that is often used when precise sunrise and sunset timings are required, and also helps with daylight savings changeover.
That’s not to say there isn’t a way of avoiding the problem in the first place, I just haven’t thought about what it is.
Something else you might like to be aware of about ‘time between’ is that the piston code always assumes that the first time occurs before the second time. So if you said ‘time is between sunset and 7:30pm’ and sunset is actually at 8:00pm the comparison is ‘between 8:00pm and 7:30pm’. If the current time is before 7:30pm webCoRE would evaluate this as true, assuming you meant 8pm last night. If the current time is after 8pm webCoRE would again evaluate it as true, assuming you meant 7:30pm tomorrow. In effect it is ‘NOT (between 7:30pm and 8pm)’. So you can probably see why many users prefer to explicitly use the latter form as it makes it clear what the calculation really is. This is the same idea as @guxdude discussed with ‘between sunset and sunrise’. It is not that webCoRE gets things wrong, it just makes it more obvious that it is right. Whichever way you choose to write things, when using a range with one or more variable times you mustn’t allow the earlier/later relationship between the limits to flip.
