Vital works with varying levels of time zone awareness across all supported providers. The following section describes the levels and how Vital works with the data in that regard.

Levels of Awareness

Cloud-based providers

At Source

Each data sample or daily summary is individually tagged with the time zone in which it was captured.

Inferred TZ or Absent

Vital tries to infer the time zone from any available geographical data. If the inferrence has failed, the data would not be tagged with any time zone.

Provider User TZ

The provider does not track time zone information on individual data samples, but do keep track of at least the latest time zone of a user.

Vital pulls and interprets data with respect to the latest user time zone as reported by the provider.

User Fallback TZ or UTC

The provider is completely time zone unaware.

Vital uses either the user’s Vital Fallback Time Zone (if specified) or UTC to both pull and tag the data.

User Fallback TZ or Absent

The provider is completely time zone unaware.

Vital uses either the user’s Vital Fallback Time Zone (if specified) or UTC to pull the data.

The data would not be tagged with any time zone, except when it is pulled using the user’s Fallback Time Zone.

Vital pulls data using UTC as the reference time zone. However, the data would not be tagged with any time zone.

SDK providers

Device TZ at Sync

Vital SDK tags all outstanding data with the current device time zone at synchronization time.

State of integrations

The following list describes the level of time zone awareness of all supported provider integrations.

Cloud-based providerActivity Summary (Daily)Session Summary (e.g. Sleep)Timeseries Sample
Freestyle freestyle_libreN/AAbsentAbsent
Fitbit fitbitProvider User TZ [1]Provider User TZ [1]Provider User TZ [1]
Garmin garminAt SourceAt SourceAbsent
Google Fit google_fitUser Fallback TZ or UTCUser Fallback TZ or AbsentAbsent
Oura ouraAt sourceAt SourceAbsent
Peloton pelotonN/AAt SourceN/A
Renpho renphoN/AAt SourceAbsent
Strava stravaN/AAt SourceAt Source
Wahoo wahooN/AAbsentN/A
Whoop whoopN/AAt SourceAbsent
Zwift zwiftN/AUser Fallback TZ or AbsentN/A
Withings withingsAt SourceAt SourceAt Source
iHealth ihealthN/AAt SourceAbsent
8Sleep eight_sleepN/AAt SourceAbsent
Hammerhead hammerheadUTC onlyInferred TZ or AbsentAbsent
Dexcom (G6 And Older) dexcomN/AN/AAbsent
Dexcom dexcom_v3N/AN/AAt Source

[1] Requires the profile Fitbit OAuth scope.

SDK providerActivity Summary (Daily)Session SummaryTimeseries Samples
Omron omron_bleN/AN/ADevice TZ at Sync
Contour contour_bleN/AN/ADevice TZ at Sync
Accu-Chek accuchek_bleN/AN/ADevice TZ at Sync
Apple HealthKit apple_health_kitDevice TZ at SyncDevice TZ at SyncDevice TZ at Sync
Freestyle Libre BLE freestyle_libre_bleN/AN/ADevice TZ at Sync

User Fallback Time Zone

Some providers neither expose nor even capture time zone information at source. So Vital can only request data and interpret them strictly in UTC.

If you prefer the data to be contextualize 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, Vital would use the time zone to pull data and interpret timestamps from any time zone unware 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.

  "user_id": "409d9870-21fb-443a-8daa-c5222659f40e",
  "team_id": "3aac677c-557f-40b7-9251-0315c1f48e77",
  "client_user_id": "d734e32e-dd43-4b77-ab56-692524279531",
  /** snipped **/
  "fallback_time_zone": {
    "id": "Europe/London",
    "source_slug": "manual",
    "updated_at": "2022-09-11T13:45:56+00:00"