fellinga/node-red-contrib-ui-time-scheduler

Date array in UTC time?

Closed this issue · 7 comments

It seems that the date array in the output json is stored in UTC?

Front end
Screen Shot 2022-08-23 at 7 20 05 PM

Backend
Screen Shot 2022-08-23 at 7 17 24 PM

Hi. Yes it is stored in UTC, based on your screenshots I expect that you live in a time zone at least 7 hours behind UTC.

What are you trying to accomplish?

I need to calculate a daily running time for the scheduler - the json output is perfectly fine for my purpose. I do live in UTC-8 (PST). I rely on the day flag to figure out what runtime I have in that specific day. However, as you can see, if I schedule something for Tue PM, the day flag is set for Wednesday. This of course screws up my calculation.

Okay, so the saved days are correct then. For someone who lives in UTC the actual days the timers go off would be Tuesday and Wednesday and this person would see it that way on your dashboard.

If you want to post process my json output for your purpose and time zone you would have to add 8 to the time and if it overlaps (>=24) you would have to adjust the calculations.

Example:
Start: 05:49 = 05+8 = 13 -> entries in days array remain the same
Start 17:50 = 17+8 = 25 -> shift all entries in days array up by one day

Does this help?

Thank you for the response. I know how I could be doing it, but the days are not ‘correct’, it should reflect reality regardless of my current TZ. I think storing them in local time instead might actually address this issue, this is why the original question. I realize not many people would actually care about this output, but it’s definitely not correct nor useful in its current form IMO. I’ll see what I can do, thanks for an otherwise very nice component.

First of all the days are definitely correct and they do reflect reality based on UTC time.

Your browser shows you the days and time for your time zone (calculated from the values stored in UTC) and my browser will display the exact same data from the JSON array for my time zone (calculated from the values stored in UTC) and this is only possible when the data is stored in a common format.

Storing them in local time is a very bad idea:

  • What are you going to store when you have a server that runs in UTC-3 and a browser that runs in UTC-7? You would have to choose either one.
  • What are you going to show to clients from a time zone UTC+2 then?

Ok, point taken. I guess then converting them to local time before sending them to the output (in sendTimersToOutput)

That doesn't make a lot of sense. The output is server side --> it has to be UTC at this point because this is where the data is being stored! And I already explained why it has to be stored in UTC..