3140223 - FAQ: SuccessFactors DataCenter time Zone as UTC

Symptom

All SuccessFactors datacenters are moving to the UTC time zone. As a result, you wish to understand whether there will be any impact to your integrations and if so, how to mitigate it.

Image/data in this KBA is from SAP internal systems, sample data, or demo systems. Any resemblance to real data is purely coincidental.

Environment

SAP SuccessFactors HXM Suite
SAP SuccessFactors BizX Platform

Cause

All SuccessFactors datacenters' time zone will change to UTC

Resolution

GENERAL

1. How can I know if I am going to be impacted and is there any documentation that can assist me?
Please refer to the See Also section below, each sap SuccessFactors area is aiming to publish module-specific information to assist with the migration. Please do not hesitate to reach out to us via the referred blogs or raise a Support case to the relevant SAP SuccessFactors component (LOD-SF*).

2. Is this migration happening at a Data Center (DC) level or at a tenant level?
The migration is happening at a DC level.

3. Are all SAP SuccessFactors servers in UTC already?
Not yet, they will be after the migration (when the relevant DC will be moved to the UTC timezone).

SCENARIO-SPECIFIC

1. MDF SCENARIOS

We do not foresee any impact to MDF-based APIs as long as customers respect the default TPT (the default value is the original server timezone).

2. TIME SCENARIOS

We do not foresee any impact to Time APIs as these are built on the MDF framework which has fields: lastModifiedBy, lastModifiedDateTime, createdBy, createdDateTime (i.e. they do not include properties such as lastModifiedOn or createdOn).

3. MIDDLEWARE SCENARIOS

a) *Standard Integration scenarios with the traditional HXM Suite (e.g. ERP or S/4)*
We do not foresee any impact for our middleware-based integrations since we have always used UTC timestamps.

b) *Custom integrations in BTP/CPI*
As a suggestion to check for potential impacts, you could go to the SAP SuccessFactors' User Interface > Audit logs, filter by the API user used (e.g. user in the middleware) and check if your API calls (request header URL) have any EC impacted field under the $filter criteria

c) *Boomi integrations*
Conversations with Boomi are ongoing to evaluate any potential impact.
NOTE: You will not be impacted if you are in DC30 as we do not host any atoms in DC30.

4. INTEGRATIONS RUNNING SAP SUCCESSFACTORS APIs

Main impact:
Audit data in SFAPI and OData API will begin to be displayed in UTC for the specific "request_time" and "response_time" fields. Also, these fields' existing audit data will move to UTC

a) There is no common nomenclature for the last modified on field with respect to all SuccessFactors APIs (e.g. "User" has just last lastModified, "EmpJob" has lastModifiedOn") - do we expect any side-effects due to this lack of common nomenclature?
No, this is not relevant for the move.

b) Will all fields be impacted by the move to UTC e.g. effectiveStartDate?
Yes. Please check for any usage of dateTime properties in your APIs.

c) The current understanding is that OData API's default dateTime format is UTC - What happens in scenarios where I am using DateTimeOffset?
(https://help.sap.com/docs/SAP_SUCCESSFACTORS_PLATFORM/d599f15995d348a1b45ba5603e2aba9b/ece4eb20a56a48b1848b59cb9985c389.html?q=datetimeoffset)
At an API Framework level, we already treat this as UTC. At an individual entity level, only EC Odata API OData APIs' 'lastModifiedOn' and 'createdOn' will provide data in UTC after migration (in other words, each API has adopted TPT to ensure the behavior remains unchanged).

d) What if I do not do anything after the UTC timechange happens in the DC, specifically what happens to the "SFODataServerTimeZone" which comes in the header response of each API call? (and does it matter whether I am on Tenant Preferred Time Zone or not)?
SFODataServerTimeZone is the API server timezone however it is not relevant for this migration as it is not in use.

e) What happens if I am using the Tenant Preferred Timezone (TPT), specifically IF...
e.1) the api fields like lastModifiedDate and start date are in "Tenant Preferred Time Zone" and these are migrated to UTC - will these fields show UTC time or remain in Tenant Preferred?
These fields should remain as TPT unless there are explicit exceptions thrown by the individual API. At this point, we are not aware of such exceptions.

e.2) I wait for the UTC time to switch and then switch the Tenant preferred timezone back to the original local timezone, how can I test this change and find out if there will be an impact to the application/integration?
The TPT value is the as same as the original local timezone before the UTC migration and will not change after the migration, meaning you do not need to set or change TPT after the migration. Any required actions are documented in the Customer Community blog or Partner Community highlighted in the See Also section below. For module-specific KBAs, please also refer to See Also below.

e.3) I want to change the current TPT to another timezone and want to understand the impact of this action.
Please review the following SAP Help page which lists some of the affected areas: https://help.sap.com/docs/SAP_SUCCESSFACTORS_PLATFORM/6c9f794920b947648737d914a669f195/22a3439ddbea498ab42d0b15b3c4c47e.html
For the missing areas (e.g. you want to understand what are the side-effects of changing the TPT for EC OData entities) please note OData date time properties always use the UTC time so we do not foresee any impact for our customers.

e.4) I am not planning to do anything after the UTC timechange happens in the DC (i.e. I am not planning to implement TPT) - will I be impacted?
If your DC is already on UTC, or you are happy to migrate, there is no action required, i.e. the UTC migration will happen automatically and the behavior of the system should remain the same. However, if you make manual changes after the migration (e.g. TPT) , this will have an impact on the rendering in the UI and the API behavior, and you may need to make aligned adjustments in the integrations using those APIs.

f) Can you share if there is going to be any known impact to any specific API?
So far, we are only aware of the following, please review carefully from your end:

5. USER MANAGEMENT SCENARIOS - SCIM API

SCIM API's input and output are already in UTC so we do not foresee any impact from this migration.

6. SFAPI Compound Employee (CE)
a) SFAPI CompoundEmployee API query expressions handle date and time in different ways, depending on whether the last_modified_on or the effective_end_date parameter is used.
Query expressions using the last_modified_on parameter consider the time zone specified in the query expression as well as the time zone stored in the database records. Last modified dates are always returned in a Universal Time Coordinated (UTC) timestamp (Guide). Will the move to UTC have any impact on this current logic?
CE API is always exposing all datetime fields in UTC and the datetime filter values need to be provided in UTC. We have a logic which converts the offset to the local time currently used at a DB level. This logic is reacting on the UTC migration, i.e. you should not face any issues or experience any differences after the UTC migration.

7. DATA REPLICATION MONITOR

The OData entities behind the Data Replication Monitor use the same logic as explained under "SFAPI Compound Employee" above and will not be affected by the migration.

8. JOB SCHEDULING, including INTEGRATION CENTER

a) Will all scheduled jobs, irrespective of Job type in provisioning, be executing as per the UTC time zone post migration?
Those jobs which are already scheduled will keep running at the same timings as before; the Job definition will show the old timezone that it was scheduled on. However, the +/- 1 hours for Daylight savings will no longer apply.

As long as you do not edit/ re-submit the job request, we at SuccessFactors will do the transformation for all our customers, meaning the jobs
will keep running at the same timestamp while the job request been created (which is based on the former scheduled timezone).
For example:
• Before migration: the job is been scheduled to run at 9:00 am shanghai time
• After migration: the job is been scheduled to run at 1:00 am UTC time (which is 9:00 am shanghai time)

Please also refer to the following screenshots (which indicate we will have clear timezone info on both job details and job create/ edit pages):

b) What will happen to existing jobs that are edited or to any newly created jobs?
The timing of such jobs will switch to UTC with the migration, so you will need to set the timings accordingly

c) How does this move impact Integration Center jobs?
In Integration Center, we always display the time in browser time zone on UI (cf. KBA 2923478)
However when the actual processing happens it is converted to UTC (and again while displaying back it will be browser’s time zone again), therefore we do not foresee any issues because of the move.

d) Can you explain the logic applied by Integration Center in relation to TPT and UTC?

For outbound integrations, the SFTP filename calculation is based on the following settings: It first prefers the "ICD timezone" field, and if not available, it uses the TPT from Platform Settings. If none of the above options are available, it defaults to the UTC timezone (see also KBA 3319377 )

However, for inbound integrations, currently it always checks the SFTP file in the UTC timezone. As this is leading to some confusion, our Development team are working to incorporate the "tenant preferred timezone" and "ICD preferred timezone" for inbound integrations as well (our internal reference is INT-16862, no ETA is available at this time).

9. ASK HR

The UTC migration will not have an impact on Ask HR as this application does not store or maintain data (Guide)

10, MASTER DATA INTEGRATION (MDI)

We do not foresee any impact at this stage (Guide)

SCHEDULE
(*Note: this KBA will be kept up-to-date with all the dates as they become available. You can also review the What's New Viewer reference TLS-26071 and the Communities blogs under the See Also section of this KBA)

Data Center

Region

Environment

Date and Time

DC30 (Shanghai)

APJ

Preview

Friday, 4th Aug 2023, 3pm UTC – 10pm UTC

DC30 (Shanghai)

APJ

Production

Friday, 15th Sep 2023, 3pm UTC – 10pm UTC

Keywords

TPT, Tenant Preferred Timezone, UTC, DataCenter, data center, DC, integration, integrations, OData, EC, datetime, timezone, time zone, TLS-26071, Date Time Fields of Employee Central OData Entities Represents UTC Time, Addition of Time Zone Resilient Date Fields , KBA , LOD-SF-INT , Integrations , LOD-SF-PLT , Platform Foundational Capabilities , LOD-SF-INT-ODATA , OData API Framework , How To

Product

SAP SuccessFactors HXM Suite all versions