No, it only changes when the event that triggers the rule is generated. If you care about the actual time (i.e. linked the start or end Channel to a DateTime Item), that DateTime Item will have the real time of dusk, not the modified earliest time on the event Channel.
All four of these Channels represent some aspect of Civil Dusk. The first three can only be linked to an Item. The last one can only be used to trigger a rule. The “earliest” property is only a property on that last Channel. It has no impact on the other three.
If you need an event for actual dusk to drive some other rule, you can use one of the other dusk set of Channels (you have astro, civic, or nautical to choose from and for a home automation purpose they are all close enough together) or you can create a second Astro Thing without the earliest set on the dusk event Channel.
Or you can deploy something like Time Based State Machine [3.2.0;3.4.9] and break your day up into all sorts of little named chunks to drive things.
Why, there’s nothing wrong with that. But I think Jim’s suggestion is that the two rules would have two different triggers, one for 7 and the other one from the Astro channel event.
This whole thread though is dangerously close to an XY Problem. It just so happens that the most efficient way to implement this also answers your original question. But this is not the only want to do it. You could do something like ignoring what caused the rule to trigger. When the rule runs check to see if now is after the state of a DateTime Item linked to the dusk start Channel. If it is close the blinds. If it’s before do nothing. But ultimately this is far more complicated because it requires an extra Item and a lot more logic than just setting the earliest time on the dusk event Channel which handles everything and all your rule has to do is send the command to the roller shutter.
I like to talk about the “home automation users.” It is more comprehensive and it forces you to think beyond immediate family. Consider your house guests too. 