Problem with timezone / schedule & input processing

Emoncms
, , ,
1

I’ve been continuing to modify my setup and read through things. This page on daily kWhr was helpful. I thought I knew how to set up my system but the schedules aren’t working as I expected. I notice the log file is in UTC - should it be? My machine is set to America/NewYork, as is now my emon user account and php.ini. I’ve restarted apache2, logged out and logged back in to my account.
So I have these schedules set up:

image
image744×259 8.63 KB

and this processing:
image
image1324×680 57.4 KB

So it is currently 9:22 on 6/20/20. It should be matching the super peak schedule and logging to the peak kWhr/day feed, but the feeds show:
image
image902×190 5.49 KB

And here is the admin page with the log file showing entries in the future - I’m thinking that this is why the off-peak schedule is running? But I can’t find any where else that I need to change the time zone?
image
image1034×665 43.3 KB

I saw discussions about the browser time zone, but that is NY time as well - and the file on the server has the timestamps in UTC within it.
Hopefully it’s something simple that I’m overlooking. Thanks for the help. :slightly_smiling_face:
image
image
image771×375 7.71 KB
image
image1078×567 46.9 KB

2

Ok, so thinking about this, I thought maybe as the schedules were created prior to setting the timezone, UTC was associated with the schedule, not the current timezone. Tbh, I’m not sure if I tried editing the schedule first or not. What I did do was recreate the schedules. That has fixed the problem.

The other thing I was not sure of, was exactly how the times played out. I’m still not 100% sure. What I have found though from looking at the code is that if a time is from 08:00 - 11:59, the code seems to treat it as 08:00:00 >= now() and now() <= 11:59:59.
I’m not sure what happens to fractions of seconds but I’m less concerned than a fraction of a second being missed. With the above schedule, if there is another schedule at 12:00 - 18:00 and the time is 11:59:59.789 what happens? Maybe the system only goes to seconds, I think the api has epoch seconds, or the sub-seconds are truncated, in which case there’s no issue.