Use DateTimeOffset in the /prices endpoint and "lastUpdated" property

[mattiaspalmqvist]

To be explicit and avoid confusion I think it would be better to use DateTimeOffset objects with trailing +NN:NN (or Z for UTC) in the /prices endpoint.

It can otherwise be a bit confusing what is actually provided in the answer and what you are asking for in requests. As a developer I would rather work with explicit DateTimeOffset in this type of time series data.

Add this object and use where relevant:

"DateTimeOffset": {
  "type": "string",
  "format": "date-time",
  "pattern": "^\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2}(?:Z|[+-]\\d{2}:\\d{2})$",
  "example": "2025-05-25T01:00:00+01:00",
  "description": "Date-time in ISO 8601 / RFC 3339 style with required numeric offset in the form ±HH:MM."
},

[larwa99]

Perhaps I'm missing something, but is there a lastUpdated property today or something that you suggest to add as well?

[mattiaspalmqvist]

Yes, in the base Tariff object.

"lastUpdated": {
    "$ref": "time.schema.json#/definitions/DateTime"
},

But, now when I think about it, maybe this is obsolete. My thoughts about this is if there are bugs or something that we should have this "lastUpdated" to declare when the tariff object was created/updated.

But since we have the idea that a tariff object, with a set UUID, should be immutable and never change it might be better to simply throw away in incorrect object and replace with a new one with a new UUID.
If we follow that pattern, the "lastUpdated" is not needed since it will never change.

---

Either we keep the "lastUpdated" and allow changes to existing objects, it's then the responsibility of the DSO to think about how such a change will affect users. This might be i more flexible approach in case of errors to published tariffs. This should be documented in the developer docs.

OR

We remove the "lastUpdated" property and add some note to the developer docs about all objects with a UUID as identifier is immutable and shall be fully replaced in case of errors to previous publications. This might cause several tariff objects to be fully replaced if a common component is changed, like a component for the energyPrice.

[larwa99]

I have seen and handled the tariff object as immutable once created and the lastUpdated is only as information when it was created. A more logical name could perhaps be creationDate or similar. Any change to the tariff object, even correcting a typo in the description text, will result in a new UUID.