Timeswitch reporting bizarre timestamp for next sunrise event

[jdmallen]

Which node are you reporting an issue on?

node-red-node-timeswitch

What are the steps to reproduce?

1. Insert into flow
2. Set Lat & Long for your location
3. Configure to turn ON at SUNSET and OFF at SUNRISE
4. Deploy and observe scheduled time to next execution

What happens?

The timeswitch node says it won't execute "until 24:10." The next event (sunrise, in my case) is actually more like 8.5 hours from now. Considering this is not a standard format for any timestamp, I suspect this is more of a presentation bug than an operational one, but I have no idea.

What do you expect to happen?

I expect it to report that it'll send "off" either in the appropriate timespan for when sunrise will actually occur for my lat/long, or "until" an actual timestamp in my local time.

BigTimer, the node-contrib that this one references in its overview page, reflects the correct time. Please see these comparison pictures:

Note the "off until 24:10" under the timeswitch.

Please tell us about your environment:

• Node-RED version: v3.0.2
• node.js version: Whatever it is in the latest nodered/node-red Docker image.
• npm version: "
• Platform/OS: "
• Browser: "

[dceejay]

well yes definitely a presentation error at the very least... -
would 24:10 (-> 00:10) be roughly the sunrise time in GMT rather than your local timezone ?

[dceejay]

pushed version 0.2.1

[jdmallen]

Wow, appreciate the quick work! I pulled 0.2.1 into NR and tried it again.

It still seems incorrect to me, using the same settings as before. We're past sunrise where I am (UTC-4), so it should be tracking the next event: sunset. However, it seems to think sunrise has not yet occurred. The current local time when I took this screenshot was about 7:20 a.m. The current status of the node should also be OFF, just like BigTimer.

[jdmallen]

It's worth noting that I have NR set to display time in 24-hour format, so "6:29" is a.m. EDT.

[dceejay]

If you change the sunrise to be a time (eg 07:00) - a timezone box should appear - what does that say ? (Ie is it correct or has it defaulted to GMT ?)

[jdmallen]

It was set correctly to America/New_York, though I did notice a promising clue. I set the timer to ON at 08:00 and OFF at 20:00 (8p), and here's what I got after deploying.

It looks like it might be over-correcting. I am indeed in UTC-4, so it should be subtracting 4 hours from the UTC time (12:38Z as of this comment, 8:38 here), but it's still treating the time in the dropdown as though it's UTC, not local, regardless of the timezone selected. That's fine for selecting specific times-- I can just know to select UTC-- but it doesn't work for sun events.

[dceejay]

OK - looks somewhat more broken than just displaying incorrectly then.. as the dropdown (and sunrise/sunset) should all be in local (specified timezone) time for the user shouldn't they... (but stored internally in GMT). hmm

[jdmallen]

Thanks @dceejay. I'll see if I can get my environment set up to do Node-Red development and maybe help out in parallel (without stepping on toes, of course).

[dceejay]

Thanks - any/all help much appreciated

[jdmallen]

Happy to help!

So I did poke around at lunch. The problem is how we're interpreting "now."

That Date object is in the Offset format. It should show as either 12:49:44 GMT-0400 or 08:49:44 GMT+0000, but not a combination of both. This is why we were seeing that excess offset of -4 hours earlier.

The reason is that we're taking the Date.now() epoch time and then applying the timezone offset to it. The problem is that epoch time does not have timezones, and so Date already represents the local time when it's evaluated by the Nodejs runtime. In order for us to properly use custom timezones in this node that differ from the timezone the user is currently in, we must first understand what the user's current timezone is.

Let's say I want to specify that this node should send a '1' in the payload when the time 7 a.m. Pacific Standard Time is encountered. I need the code to know that the start time is -3 hours from where I am before it presents me with the "OFF until 10:00" message. Right now, it does not appear to be doing that.

Utilizing a more robust DateTime library like Moment (node_modules ~= 6 MiB) or Luxon (node_modules ~= 4 MiB) would mitigate this pretty easily. The current library, spacetime (node_modules ~= 0.5 MiB), is pretty powerful, but does not appear to supply a getter for a complete DateTime object, string, or epoch, which makes it a bit trickier to work with. However, I did see your notes in a previous PR about wanting to keep this library lightweight, so I'll play around a bit more with the code this evening and see if I can get this to play nice.

[jdmallen]

So... I fixed it. But I did a lot of other things, too. Mostly to make more use of the spacetime library (since it's there), and to make it a bit easier to read.

Before I dare make a PR, figured you might want to take a gander. I tested multiple scenarios, including sun events, Start + X Minutes, months or days of week disabled/enabled, sun event offsets, etc. I think it's working pretty well. Even obscure cases when the OFF time is sunset, but sunset happens to be a couple minutes before the ON time:

...it behaves as expected:

Eager to learn your thoughts.

[dceejay]

Hi - Actually it's much easier for me to test if it is a PR - so please go ahead !
Looks good to me.