Time zones
You can specify a time zone for an identity in the Timezone property of the Users view. If you do not specify a time zone, the system uses the default time zone specified in the customer setting Default time zone (in the Customer settings view). The default time zone is 105.
Click to check out the supported time zones
| Code | Time zone |
|---|---|
| 0 | (UTC-12:00) International Date Line West |
| 1 | (UTC+13:00) Samoa |
| 2 | (UTC-10:00) Hawaii |
| 3 | (UTC-09:00) Alaska |
| 4 | (UTC-08:00) Pacific Time (US & Canada) |
| 10 | (UTC-07:00) Mountain Time (US & Canada) |
| 13 | (UTC-07:00) Chihuahua, La Paz, Mazatlán |
| 15 | (UTC-07:00) Arizona |
| 20 | (UTC-06:00) Central Time (US & Canada) |
| 25 | (UTC-06:00) Saskatchewan |
| 30 | (UTC-06:00) Guadalajara, Mexico City, Monterrey |
| 33 | (UTC-06:00) Central America |
| 35 | (UTC-05:00) Eastern Time (US & Canada) |
| 40 | (UTC-05:00) Indiana (East) |
| 45 | (UTC-05:00) Bogota, Lima, Quito, Rio Branco |
| 50 | (UTC-04:00) Atlantic Time (Canada) |
| 55 | (UTC-04:00) Caracas |
| 60 | (UTC-03:30) Newfoundland |
| 65 | (UTC-03:00) Brasilia |
| 70 | (UTC-03:00) City of Buenos Aires |
| 73 | (UTC-03:00) Greenland |
| 80 | (UTC-01:00) Azores |
| 83 | (UTC-01:00) Cabo Verde Is. |
| 85 | (UTC+00:00) Dublin, Edinburgh, Lisbon, London |
| 90 | (UTC+00:00) Casablanca |
| 95 | (UTC+01:00) Belgrade, Bratislava, Budapest, Ljubljana, Prague |
| 100 | (UTC+01:00) Sarajevo, Skopje, Warsaw, Zagreb |
| 105 | (UTC+01:00) Brussels, Copenhagen, Madrid, Paris |
| 110 | (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna |
| 113 | (UTC+01:00) West Central Africa |
| 120 | (UTC+02:00) Cairo |
| 125 | (UTC+02:00) Helsinki, Kyiv, Riga, Sofia, Tallinn, Vilnius |
| 130 | (UTC+02:00) Athens, Bucharest |
| 135 | (UTC+02:00) Jerusalem |
| 140 | (UTC+02:00) Harare, Pretoria |
| 145 | (UTC+03:00) Moscow, St. Petersburg |
| 150 | (UTC+03:00) Kuwait, Riyadh |
| 155 | (UTC+03:00) Nairobi |
| 158 | (UTC+03:00) Baghdad |
| 160 | (UTC+03:30) Tehran |
| 165 | (UTC+04:00) Abu Dhabi, Muscat |
| 170 | (UTC+04:00) Baku |
| 175 | (UTC+04:30) Kabul |
| 185 | (UTC+05:00) Islamabad, Karachi |
| 190 | (UTC+05:30) Chennai, Kolkata, Mumbai, New Delhi |
| 193 | (UTC+05:45) Kathmandu |
| 195 | (UTC+06:00) Astana |
| 200 | (UTC+05:30) Sri Jayawardenepura |
| 203 | (UTC+06:30) Yangon (Rangoon) |
| 205 | (UTC+07:00) Bangkok, Hanoi, Jakarta |
| 207 | (UTC+07:00) Krasnoyarsk |
| 210 | (UTC+08:00) Beijing, Chongqing, Hong Kong, Urumqi |
| 215 | (UTC+08:00) Kuala Lumpur, Singapore |
| 220 | (UTC+08:00) Taipei |
| 225 | (UTC+08:00) Perth |
| 227 | (UTC+08:00) Irkutsk |
| 230 | (UTC+09:00) Seoul |
| 235 | (UTC+09:00) Osaka, Sapporo, Tokyo |
| 240 | (UTC+09:00) Yakutsk |
| 245 | (UTC+09:30) Darwin |
| 250 | (UTC+09:30) Adelaide |
| 255 | (UTC+10:00) Canberra, Melbourne, Sydney |
| 260 | (UTC+10:00) Brisbane |
| 265 | (UTC+10:00) Hobart |
| 270 | (UTC+10:00) Vladivostok |
| 275 | (UTC+10:00) Guam, Port Moresby |
| 280 | (UTC+11:00) Magadan |
| 290 | (UTC+12:00) Auckland, Wellington |
| 300 | (UTC+13:00) Nuku'alofa |
Date time values are displayed and assumed to be provided in the signed-in users time zone set in My Settings of the signed-in user. If the user's operating system's time zone is different than their time zone, an invalid conversion may occur while saving the value of the data object or customer setting. Therefore, it is required that the user's time zone is the same as the operating system's time zone.
RoPE uses the identity time zone to adjust (extend) the Valid From and Valid To dates specified on the Identity, Resource assignment, and Context assignment data objects, so that Valid From is at 00:00 and Valid To is at 23:59 in the identity's own time zone.
Additionally, the system can adjust (extend) the Valid From and Valid To dates specified in the Assignment policies and Resource data objects, so that Valid From is at 00:00 and Valid To is at 23:59 in the default time zone.
If your installation of Omada Identity relies on Time Zones other than the default (UTC+01:00) Brussels, Copenhagen, Madrid, Paris for validity periods, it is crucial that the Time Zone attribute has the same value on the Identity object and the related User object.
Time zone adjustments occur only when RoPE is set up to extend validity periods using the extendValidityPeriods setting in the RoPE config file, which is enabled by default.
The Valid From and Valid To properties, by default, do not include the time component.
Hence, if the extendValidityPeriods setting is set to True, avoid adding times to these properties, as they are configured to not contain a time component.
Date-time fields across Time zones
As it is described in the Time zones section above, RoPE adjusts Validity periods according to the time zone in which the concerned Identity resides.
In such a case, the Valid from date is always interpreted as 00:00:01 of this date in the Identity's time zone, while the Valid to date is always interpreted as 23:59:59 of this date in the Identity's time zone.
The diagram below presents an example of the validity period of an account adjusted to the Identity time zone:
An account is created in Copenhagen time zone for an identity residing in Tokyo. The account is created in the system once on January 22, so it is 10:00 of the Copenhagen time and 17:00 of the Tokyo time.
The Valid from date for this account is set for February 1. In consequence, the account becomes valid at 00:01 February 1 Tokyo time in the Tokyo time zone, and at 00:01 February 1 Copenhagen time in the Copenhagen time zone. This difference means that the account in Tokyo becomes valid 7 hours before it becomes valid in Copenhagen.
A similar situation takes place with the Valid to date. The account is disabled at 23:59 Jul 31 Tokyo time in the Tokyo time zone, and at 23:59 Copenhagen time in the Copenhagen time zone. Again, the account is blocked 7 hours earlier in Tokyo than in Copenhagen.