[Solved] Arm for Eastern Standard Time/Daylight Saving Time
-
Where are our
latchingexperts?Daylight Saving Time here in the States has begun. I'd like to create a couple "Arm for" rules for potential referencing for iblinds rules.
- DST starts the second Sunday in March at 02:00 ET.
- EST starts the first Sunday in November at 02:00 ET.
Here's what I have so far:
And the latching:
I've done the trick with changing the
test datediscussed in another thread here that allows for time travel back to when the latch should start. It took a few attempts and I finally had it do the 03:00 ET hour because, technically, the 02:00 ET doesn't exist during the transition to DST.Current status:
Anyone with experience with this feel free to heckle my work with the goal being to beat this thing into submission
-
I tried to follow your example but I'm confused. Shouldn't the "and the rest" rule start on April 1st instead of March 1st? I'm definitely not a latching expert, so maybe I'm the wrong person to try to understand what you've done.
Not being competent with latching, the approach I would probably take would be to create an expression 'is_dst' and have a rule that sets it to true on the second Sunday of March at 0300 and sets it to false on the first Sunday in November at 01:59:59. Initially set it to the correct value and then just refer to the expression whenever a rule needs to know if DST is in effect. Seems simpler to me and I think it would work just as well.
My state legislature is considering a bill to stay on DST permanently. It would require federal approval, so it's probably not going to happen anytime soon, but there's another way to solve the problem.
-
I tried to follow your example but I'm confused. Shouldn't the "and the rest" rule start on April 1st instead of March 1st? I'm definitely not a latching expert, so maybe I'm the wrong person to try to understand what you've done.
Not being competent with latching, the approach I would probably take would be to create an expression 'is_dst' and have a rule that sets it to true on the second Sunday of March at 0300 and sets it to false on the first Sunday in November at 01:59:59. Initially set it to the correct value and then just refer to the expression whenever a rule needs to know if DST is in effect. Seems simpler to me and I think it would work just as well.
My state legislature is considering a bill to stay on DST permanently. It would require federal approval, so it's probably not going to happen anytime soon, but there's another way to solve the problem.
-
@alan_f Are you doing this as two sep rules or building the start/end Sunday dates into a single rule?
And if you vote for ME as POTUS in 2024 I'll make every effort to get DST to be Daylight Standard Time and not Daylight Saving Time!
@gwp1 I'm not actually doing this, that was just my thoughts on how it could be done (= untested speculation
). I think it would have to be two rules. That way each rule is firing at one specific date and time and you wouldn't be trying to create a rule that is active at all dates and times between DST start and DST end, which I think leads you down the OP's path using latching. If you have one rule with a reset action there's no need for the expression, you could just use the rule state to tell if it's DST. -
@gwp1 I'm not actually doing this, that was just my thoughts on how it could be done (= untested speculation
). I think it would have to be two rules. That way each rule is firing at one specific date and time and you wouldn't be trying to create a rule that is active at all dates and times between DST start and DST end, which I think leads you down the OP's path using latching. If you have one rule with a reset action there's no need for the expression, you could just use the rule state to tell if it's DST.@alan_f I gave it some thought last night and came to the same conclusion: two rules, each essentially recording the variable at the designated trigger time/s.
Using the Test Date functionality in
reactor.yamlI was able to trigger the DST start successfully.That's the joy of MSR: more than one way to the end game.
-
Where are our
latchingexperts?Daylight Saving Time here in the States has begun. I'd like to create a couple "Arm for" rules for potential referencing for iblinds rules.
- DST starts the second Sunday in March at 02:00 ET.
- EST starts the first Sunday in November at 02:00 ET.
Here's what I have so far:
And the latching:
I've done the trick with changing the
test datediscussed in another thread here that allows for time travel back to when the latch should start. It took a few attempts and I finally had it do the 03:00 ET hour because, technically, the 02:00 ET doesn't exist during the transition to DST.Current status:
Anyone with experience with this feel free to heckle my work with the goal being to beat this thing into submission
@gwp1 I thought I'd chime in on this. The latest release includes a
dstflag in the Sun Information entity as a simplification, but here's my version using conditions, because I think it's useful to have more examples with latching to ponder:
The first subgroup, named "Start", detects the start of DST (here in the US, second Sunday in March). at (or after) 2am. This group is the latching element, so the group itself has the latched option enabled. Once it goes true, it remains latched true until its peer group, named "End", goes false.
The second subgroup, "End", detects the end of DST (the first Sunday in November for US). It is a NOT AND group, meaning it is true except after 2am on the change date. At that time, it goes false, and this allows the latched "Start" group to reset.
The key thing to remember is that a latched condition (either a single condition or a group) must be paired in an AND group with at least one other non-latched condition that can reset it. Since the "Start" and "End" groups are contained in the rule's enclosing AND group, that serves the function.
S. 623 was passed by the US Senate on March 15 and is on its way to the House. If it passes, then at least here in the US, we may soon not need to worry about any of this.
-
@gwp1 I thought I'd chime in on this. The latest release includes a
dstflag in the Sun Information entity as a simplification, but here's my version using conditions, because I think it's useful to have more examples with latching to ponder:The first subgroup, named "Start", detects the start of DST (here in the US, second Sunday in March). at (or after) 2am. This group is the latching element, so the group itself has the latched option enabled. Once it goes true, it remains latched true until its peer group, named "End", goes false.
The second subgroup, "End", detects the end of DST (the first Sunday in November for US). It is a NOT AND group, meaning it is true except after 2am on the change date. At that time, it goes false, and this allows the latched "Start" group to reset.
The key thing to remember is that a latched condition (either a single condition or a group) must be paired in an AND group with at least one other non-latched condition that can reset it. Since the "Start" and "End" groups are contained in the rule's enclosing AND group, that serves the function.
S. 623 was passed by the US Senate on March 15 and is on its way to the House. If it passes, then at least here in the US, we may soon not need to worry about any of this.
@toggledbits I saw your release notes and immediately dropped 22080 in place and went straight to the
variablerules I'd built from @Alan_F's comment and disabled them in favor of the system's SunInfodstflag. I didn't delete the others - I really want to fully grasp latching.I'm not holding my breath on the possible law - it was written back in 2021 and the House keeps putting it in committee.
Fingers crossed!
-
T toggledbits locked this topic on
