In this article, we will be talking about the time expression used, when inserting readings in the platform through API. Specifically, we’ll go through the following topics:
Introduction
When inserting data on the Energy Management Platform, it is important to understand the relation between the Reading time and the insertion time and also the different ways we can express the time when this happens. A bad configuration could end up with Reading misalignments or data gaps.
Nomenclature
First, let’s define the different concepts that involve this topic:
- Time stamps: print of the exact moment in a specific time zone and format.
- Time zone: local time of the data source.
- Insertion time: time when the Reading is received by the platform.
- Reading time: time when a Reading took place.
-
Historical Reading: value read before the last inserted value. It’s insertion time is after the Reading time.
-
Future Reading: value inserted before it’s Reading timestamp. This value is understood as forecasted.
How do time stamps work?
There are different ways we can express the local time of a specific place, in order to do so, it’s important to know that the local time can be affected by the time zone of the territory and the DST (Daylight Saving Time).
The Zulu time or UTC (Coordinated Universal Time), is the global standard time reference. It is used to synchronise clocks worldwide, this system is constant throughout the year (it’s not affected by DST), meaning it serves as neutral reference for all local times.
To express the time using this format, we can either use a Z suffix or add +00:00 (indicates no offset respect the UTC reference). Using the general abbreviations, it would be represented as:
YYYY-MM-DDThh:mm:ssZ
YYYY-MM-DDThh:mm:ss+00:00
YYYY-MM-DDThh:mm:ss+0000
The local time of a site is affected by the DST and the offset respect the UTC time, for example in Spain, during the summer time the UTC offset is UTC+02:00 while during winter is UTC+01:00.
How can the readings be inserted?
As we’ve mentioned before, the readings can be inserted as future readings, historical readings, or the most common one which are the instant readings. This last type are the readings which are inserted in the platform just after the measurement.
It’s important to use the time stamps correctly when inserting data in the platform, as if they are not correct, the Reading time understood by the platform, could end up generating a future Reading and therefore triggering the No Data Alert.
The correct timestamps formats, that can be understood by the platform are:
YYYY-MM-DDThh:mm:ssZ: when using Zulu time, so when there’s a DST correction, the timestamp should be corrected.
YYYY-MM-DDThh:mm:ss+00:00: when using UTC format, as the previous option, if there’s a DST correction, the timestamp needs to change, the platform can also understand this format as YYYY-MM-DDThh:mm:ss+0000.
YYY-MM-DDThh:mm:ss: when using this format, the platform Will insert the Reading in the time zone set on the data source configuration, taking into account the DST correction by itself.
Example: London summer time
Let’s do an example, imagine we want to insert a reading in a data source from London on September 23rd at 12:00. First we’ll see the UTC time versus the London time and with the DST correction (Summer time):
As the date we want to make the insertion is with the DST correction, we need to use the UTC+01:00. Considering the data source is set in the London timezone, the correct time stamps would be:
2025-09-23T12:00
2025-09-23T11:00Z
2025-09-23T11:00+01:00
2025-09-23T11:00+0100
If instead we inserted the reading on December 11th, we would have used the UTC+00:00, meaning that the correct timestamps would have been:
2025-12-11T12:00
2025-12-11T12:00Z
2025-12-11T12:00+00:00
2025-12-11T12:00+0000
If we decided to use the Zulu time format, without taking into account the DST correction, it would have translated to a reading to the future.