Format of timestamp

When reading data values from a histdata channel the timestamp provided with each data record has varying length…
Some timestamps are longer than what one would expect assuming YYYYMMDDHHMMSS as format … How come?


Short answer: there may be milliseconds (up to 3 digits)

Detailed explanation:

On the backend API, a fully qualified timestamp always looks like this:


Which is equivalent to ISO “2019-09-09T05:59:06.035Z” (API stamps are UTC based).

  • YYYY - 4 digit year
  • MM - 2 digit month (/w preceding ‘0’ if required)
  • DD - 2 digit day of month (-"-)
  • hh - 2 digit hour (-"-)
  • mm - 2 digit minutes (-"-)
  • ss - 2 digit seconds (-"-)
  • zzz - 3 digit milliseconds

To reduce data volume, especially when retreiving many histdata (time series) records, the rightmost zeros are stripped away. The cut may occur at any position, even between 10- and 1-places:

Conversion into a Javascript Date object may be done like that:

    function stampToDate( stamp) {
        const s= stamp+'0000000000'; // max. number of cutted zeros is "Dhhmmsszzz" since DD has at least one none-zero digit "X0"
        const ms= Date.UTC(
            s.substr(0,4), s.substr(4,2)-1, s.substr(6,2), 
            s.substr(8,2), s.substr(10,2), s.substr(12,2), s.substr(14,3));
        return new Date( ms);
  • Stamps born by the backend have always a resoution of 1ms.
  • Stamps generated by a device have either 40bit (stamp40, default) or 32bit (stamp32, custom fields only) storage size.
    • The stamp32 has a resolution of 1s (e.g. zzz is always “000”).
    • The stamp40 extends a stamp32 by an 8bit fraction of a second which ends up in a resolution of approx. 3,9ms (N/256s rounded towards next full millisecond).