Skip to main content

Timestamps

All Junction data timestamps are ISO 8601 formatted as follows:
[1] freestyle_libre specific: Some older teams may see floating time data (Freestyle Libre) without the +00:00 TZ specifier, as part of an earlier iteration of the feature. Contact Junction support if you wish to disable this behavior, or if you intend to adopt the Junction backend SDKs.
[2] Floating time is not affixed to any time zone. This is not the same as time relative to a local time zone, i.e., a known UTC offset or geographical location.
[3] Junction sends timestamps in floating time with +00:00 for OpenAPI 3.x interoperability. OAS 3 requires all timestamps to be RFC 3339, which in turn requires a TZ specifier to be mandatory.When processing data from Freestyle Libre, you should reinterpret literally the date and time components as local date-time in the desired time zone. Do not convert from UTC/Zulu.

Time Zones

Junction formats time zones in data as a nullable integer offset to UTC:
  • A positive offset indicates east of UTC.
  • A negative offset indicates west of UTC.
  • null indicates the time zone information is absent.
Each provider has their own affinity of time zone information:

Cloud-based Providers

SDK-based Providers

On-device data often do not capture the time zone at recording time. Junction SDK uses the device’s current time zone as the closest approximation.

Examples

Data point with time zone offset

The data point was recorded on July 7, 2023 at 1:00 PM in UTC-07:00.

Data point with no time zone offset (null)

The data point was timestamped to Aug 13, 2023 at 8:12 AM in UTC+00:00 (Zulu). We do not know the exact time zone the recording took place in.

Data point in floating time (Abbott LibreView & Freestyle Libre)

This Freestyle Libre data point was recorded on Sep 27, 2023 at 7:48 AM in floating time (whichever time zone the user was in). We do not know the exact time zone the recording took place in. You can display the date and time components literally to the user, e.g., 2023/09/27 07:48 AM, as they are relative to their perception of local time. If you need to convert it to UTC for persistence, you need to pick a time zone based on your understanding of the user. Then you should reinterpret the date and time components literally in said time zone. For example, we knew that this example user is based in America/New_York. So we would interpret this data point to be in 2023/09/27 07:48 AM ET. We then finally convert this to UTC, resulting in 2023/09/27 11:48 AM UTC.

User Fallback Time Zone

Some providers neither expose nor even capture time zone information at source. So Junction can only request data and interpret them strictly in UTC. If you prefer the data to be contextualized to the geographical location of a user, a Fallback Time Zone (denoted by an IANA tz database identifier) can be specified on a per-user basis. Once specified, Junction would use the time zone to pull data and interpret timestamps from any time-zone-unaware providers from that point onwards. You can specify the Fallback Time Zone when: You will also get information about the source (by slug) and the last updated time of the Fallback Time Zone when getting an existing user. Fallback Time Zone manually supplied via the REST API would always have a source slug of manual.
Example