SAP Knowledge Base Article - Public

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

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*
At this stage we do not foresee any potential impact.
NOTE: You will not be impacted by the migration 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.

e.5) Will I be impacted if I'm using Local Server Timestamps (in other words, can I continue filtering using a local timestamp post UTC migration)? If so, what action do I need to take?
You will need to review your integrations if you are using the local server timestamp. Please take into account the following:

So in a scenario where you are filtering using the local timestamp post UTC migration, you will need to:



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:

g) Will there be data loss in integration extraction for the first 12 hours after UTC migration? And if so (to prevent the data loss), how should the OData API query calls for delta extraction be adjusted?
Please see review point e.5) above in detail

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.

b) What are the implications if I'm using TPT, especially in delta/period delta mode?
Compound Employee API handles all timestamps in UTC like described here: Date/Time Handling | SAP Help Portal

Tenant Preferred Time Zone is correctly considered but all timestamps are converted to UTC.
It is a key feature of the used queryMode "periodDelta" that all future changes of effective-dated entities are supressed until they become effective and are picked up on this day:

https://help.sap.com/docs/SAP_SUCCESSFACTORS_EMPLOYEE_CENTRAL/5bb9a5b997a843c88e769a105e4af4d4/462ba0644e604894ac12ad2230da35a2.html?locale=en-US

(i.e., as explained above, this has nothing to do with TPT but the way timestamps are handled in Compound Employee)

c) Will there be data loss in integration extraction for the first 12 hours after UTC migration? And if so (to prevent the data loss), how should the OData API query calls for delta extraction be adjusted?
All timestamps in CE API are in UTC. Along with the data migration the relevant time zone for our calculation is changed on the server, so finally there is no difference in our response 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 scheduled to run at 9:00 am Shanghai time
•    After migration: the job is 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 information 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

DC70 (Virginia)

AMER

Preview

Friday, May 10th, 2024, 4 AM – 11 AM UTC

DC70 (Virginia)

AMER

Production

Saturday, June 22nd, 2024, 4 AM – 11 AM UTC

DC68 (Virginia)

AMER

Preview

Monday 29th July, 4am UTC – 11am UTC

DC68 (Virginia)

AMER

Production

Saturday 21st Sep, 4am UTC – 11am UTC

DC57 (Amsterdam)

EMEA

Preview

Monday, 22nd July 2pm UTC - 9pm UTC

DC57 (Amsterdam)

EMEA

Production

Friday, 30th Aug 10pm UTC - Saturday 31st Aug 5am UTC

DC33 (Frankfurt)

EMEA

Preview

Not applicable

DC33 (Frankfurt)

EMEA

Production

Friday 6th Sep 10pm UTC - Saturday 7th Sep 5am UTC

DC66 (Sydney)

APJ

Preview

Monday 12th Aug 10am UTC - 5pm UTC

DC66 (Sydney)

APJ

Production

Friday 13th Sep 3pm UTC - 10pm UTC

DC40 (Virginia)

AMER

Preview

Not applicable

DC40 (Virginia)

AMER

Production

TBD

See Also

Module-specific KBAs:
Analytics
General - 3101935
Story - 3106280 
Legacy tools - 3106255
WFA on Hana - 3353113

Platform

General - 3355151
Impact on Platform and Metadata Framework (MDF) - 3360608

Recruiting

General - 3047665

LMS    
General - 3362023

Talent    
Impact on Performance Management (PM) & 360-MTR: 3362299
Impact on Compensation Management (CMP): 3362362

Recruiting
3047665 - Recruiting Management Adhoc and Story reports New columns added (Timestamp) and SFAPIs New Fields for Date type fields
3360987 - Job Application Standard Date Fields Showing Wrong Value - Recruiting Management

Employee Central    
General - 3362155

 

Tenant Preferred Timezone:
WNV: Updates to Tenant Preferred Time Zone
Admin Center Guide: Tenant Preferred Time Zone

Integration Center:
3319377 - Integration Center not putting the right timestamp in SFTP output filename

Blogs:
Customer Community Blog
Partner Community Blog

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 HCM suite all versions

Attachments

Pasted image.png
Pasted image.png
Pasted image.png
Pasted image.png