Adding (batch) status with TZ = UTC and having PVOutput map it?

Ideas
#1

I’m working on making it as easy as possible to upload heatpump consumption data to PVOutput for non-programmers. I’m hopeful it’ll help drive heatpump adoption for those who are skeptical or scared of making the switch.

As part of that, I’d like to remove any possible confusion/problems around timezone configuration on either the client side or the server (PVOutput) side.

Considerations:

  • UNIX timestamps are UTC. Converting these to YYYYMMDD and HH:MM is trivial.
  • Per the API docs, some endpoints support a tz parameter, but most don’t.
  • PVOutput.org has a timezone setting for every system, this is easy for a user to configure once and then forever forget
  • PVOutput’s per-system settings already have some settings wrt TZ handling: General → Timezone has Data will be adjusted to your selected timezone above as its help text, System → Live settings → Timezone has the same help text, but there’s also System → Adjust for DST has Update time sent to the API for devices that do not support DST as help text.

⇒ it’s trivial to upload data to PVOutput in UTC; this also avoids incorrect TZ configuration on the client
⇒ PVOutput already says in multiple places “data will be adjusted to time zone”, so … it should work
⇒ the Adjust for DST setting links to Live Data — PVOutput documentation, and has rather confusing help text, where it claims to only apply to generation data, not consumption data and claims to only apply a 1-hour time offset for DST? :thinking:

So: what do you recommend? Ideally, I’d upload everything with tz=UTC and have PVOutput convert as needed.

I already experimented with this. Over at G2C — HP inside 0.050kW, I am already uploading using UTC date + time, the system is already configured to my time zone (Europe/Brussels, with currently summer time active, so: CEST), with Adjust for DST off, but the data is not adjusted to my timezone (+0100 and due to summer time currently +0200).

The charts/data are off by 2 hours from the actual clock time, i.e. they’re literally respecting the precise data I provided rather than computing the proper offset.

Looking forward to your recommendations! :blush:

1 Like
#2

Its possible to add “ts” (unix timestamp) as an alternative to the current “d” and “t” parameters.

The system should have timezone configured however.

Changing this to an ‘idea’.

1 Like
#3

Interesting!

Does that mean I can send a UNIX (i.e. UTC) timestamp and as long as it is aligned to 5-min intervals, it will get converted to the right HH:MM automatically?

So: 1683464100 is 12:55 today UTC, but 14:55 in Brussels (CEST). If I send a request with 1683464100 it will get displayed as 14:55 if my system’s time zone is Europe/Brussels?

#4

Its possible to add “ts” (unix timestamp) as an alternative to the current “d” and “t” parameters.

Tried that with addstatus, but I get:

Bad request 400: Invalid Time [null]

Further, how would I be able to do that using addbatchstatus, since there’s no explicit d and t parameters there, just a sequence of parameters?

#5

This is just a suggestion for future enhancement to the API.

#6

Oh, hah, sorry! :sweat_smile:

#7

Facing a similar problem, why don’t you add a capital T for uploads in UTC and a lower case t for input in local time?

Clarification - are date times in local or UTC
#8

So what is the suggested solution currently?

Is the PVOutput System Settings page wrong when it says it will convert data to the systems timezone?
image

Currently i upload the data and time as UTC, as that’s what my inverters API returns, and that’s what the uploader i’m using (PVStats) does. I was expecting PVOutput to convert the time to my local time when viewing the chart.

But all my generation is showing up with a 12 hour offset (we are UTC+12) which leads me to conclude i need to ignore ignore what the UI says, and do my own adjustment to localtime in the uploader before calling addStatus ?

If that’s the case, can the UI be updated to remove the text Data will be adjusted to your selected timezone?

Could the API specification for add status be updated to give guidance on expected timezone?
Just a little footer on the table would go a mile 2.Date and time should be in the local timezone of the system
https://pvoutput.org/help/api_specification.html#id2

Thanks.

#9

The time would need to be adjusted to local time before sending to Add Batch/Status

Timezone is still used for PVOutput Auto Upload devices.

#10

how about clarification on the API spec?