Daylight Saving Time and General UDT Questions

[Mike Nash]

1) If I COPY a Year, Month, Day, Hour, Minute, Second into a UDT, but don't know what DayOfWeek that is
to copy in, the DayOfWeek will remain at 0 (SUN).
Currently, I can DT2EPOCH and then EPOCH2DT to get the DayOfWeek calculated and put back into the UDT. Is
there another method of finding the DayOfWeek?

2) With the above, I can now calculate the Spring And Fall DST times in a MATH instruction as a DINT,
either as  Greenwich Mean Time (or whatever it's called these days - UTC? UTC seems to get used to mean
the DINT of whatever time zone you want?) Local DINT then EPOCH2DT gets the 2AM change times. Offsetting
by timezone for March and timezone - 1 hour then EPOCH2DT for GMT gets UTC times I don't have to worry
about funny loops that falling back an hour can create. Note: I am using the DINT of the GMT UTC
(whatever!) in a MATH to set/reset $SummerTime.

3) Now an oddity. I can use SETTIME and a UDT to set the clock, either Local or GMT at any time in
ladder. I can't set the clock in the roughly one hour area just before the fall DST end from PLC > Set
PLC CLock... DmD is playing some kind of game setting the local time and I wind up an hour off on the GMT
time. Of course this is only happening during that 1 hour-ish DST End time. The $SummerTime state,
ticking the "Daylight Savings (sic) Time (+1hr)" tick box, and the time entered into the manual settings
all seem to play into this. Regardless, I cannot set the correct time in DmD just before DST ends using
any DST code I have tried to automatically adjust $SummerTime.

4) Just how does the Do-more calculate the day of week? I didn't have much luck finding any actual procedure
online as to how any of the Epoch to Date conversions are made either way.

5) The code in the screenshot is random available element grabs while I was testing this. This is DmD 2.3
because I'm waiting on 2.6.x to flash my test PLCs.

[franji1]

1 & 4) There is a realtime clock in the PLC that does all the work for calculating the Day of Week.  So using the DT2EPOCH and EPOCH2DT for that purpose is the way to do that. 

2 & 3)  I am guessing that when you use UTC with SETTIME, it takes into account the CURRENT $SummerTime bit (ST768, oh and $TimeZone DST384) to calculate the Local time.

Try calling SETTIME with the same UTC value WITH and WITHOUT the $SummerTime bit set.  You should get 2 different local times.  Use ladder logic to SET/RST the $SummerTime bit.  What's throwing a wrench into this is that you are trying to determine WHETHER YOU NEED to set that bit.

I would try calling SETTIME with $SummerTime ALWAYS OFF, then tweak it AFTER that (if it needs to be SET).  So tweak your algorithm appropriately with the assumption that you will ALWAYS be calling SETTIME with $SummerTime OFF.

[Mike Nash]

1 & 4) There is a realtime clock in the PLC that does all the work for calculating the Day of Week.  So using the DT2EPOCH and EPOCH2DT for that purpose is the way to do that.

OK, just looking for a more compact alternative.

2 & 3)  I am guessing that when you use UTC with SETTIME, it takes into account the CURRENT $SummerTime bit (ST768, oh and $TimeZone DST384) to calculate the Local time.

3) I was thinking SETTIME Local wasn't causing an issue, rather it was only in Do-more Designer's Set PLC Clock that I wasn't able to correctly set the time manually if it was within the Fall DST End area I was trying to set it to.

But I was wrong. I just tried SETTIME Local and it has a similar (or the same?) issue.

SETTIME UTC doesn't appear to take anything into account, it just wants GMT. I was able to take the desired local time and DT2EPOCH, MATH that DINT - timezone*60 - 3600 EPOCH2DT the MATH result and use it to SETTIME UTC. This works well, but is even more voluminous.

I should have tried to nail it down more definitively, but DST is confusing enough already.

Hmm, while correcting this reply, I lost comms to the H2-DM1E...  Strange, but I got it back.

UDT18 in the image below has the wrong DayOfWeek because I used DataView to enter the date fields, didn't do that one, and it was a leftover DayOfWeek from a previous use.

[Controls Guy]

4) Just how does the Do-more calculate the day of week? I didn't have much luck finding any actual procedure
online as to how any of the Epoch to Date conversions are made either way.

This doesn't seem any cleaner than using the built-in functions, but if you want you can do

Code: [Select]

MATH DayOfWeek "((DST21 / 86400) - 3) % 7"  // You can substitute +4 for the -3 obviously, if preferred
DST21 ($UTC) is a DINT containing the number of seconds since midnight, 1/1/1970.  86400 is the number of seconds in a day.  Apparently New Year's Day wasn't on Sunday that year, or you wouldn't need to adjust with the -3/+4.

You could apply the same procedure to random dates (without even having to divide by seconds), so long as you remember to include leap days.  Technically, a leap year is any year divisible by 4 but not by 100, unless it's also divisible by 400, but since Y2K is one of the exception-exceptions, we can just assume it's any year divisible by 4.

[Mike Nash]

This doesn't seem any cleaner than using the built-in functions, but if you want you can do

Code: [Select]

MATH DayOfWeek "((DST21 / 86400) - 3) % 7"  // You can substitute +4 for the -3 obviously, if preferred
DST21 ($UTC) is a DINT containing the number of seconds since midnight, 1/1/1970.  86400 is the number of seconds in a day.  Apparently New Year's Day wasn't on Sunday that year, or you wouldn't need to adjust with the -3/+4.

You could apply the same procedure to random dates (without even having to divide by seconds), so long as you remember to include leap days.  Technically, a leap year is any year divisible by 4 but not by 100, unless it's also divisible by 400, but since Y2K is one of the exception-exceptions, we can just assume it's any year divisible by 4.

Thanks, that answers one question. You seem to be the king of handy formulas! You are right that the EPOCH2DT is probably more understandable. I was able to use the MATH to do the same thing using D8 in place of DST21. I could munge that into my "when to change DST" MATH instructions, but they're contorted enough already.

Maybe someday we will have some instruction/elements that describe when and by how much DST should change and have it do it by itself. Then we just fill out that stuff in an HMI screen so the user can adjust it when needed.

[Controls Guy]

I actually had to brute-force program the DST cutover in a ControlLogix once.  Ticking the "Use DST" box is considered a fundamental enough change that you can't do it in a runtime edit, and the CLX was running half the mill. 

The company that wrote the program is in Arizona, which doesn't have DST, and the site was in Nevada, which does.  Fortunately, the CLX lets you write to the clock, so you can do your own DST if you really have to.