From 7e49033aae06d75dfb22b1ed86ce46cd87bf68ba Mon Sep 17 00:00:00 2001 From: dc-bot Date: Fri, 4 Sep 2026 10:20:08 +0000 Subject: [PATCH] docs: remove customer-identifying details from timezone troubleshooting section --- docs/dci-troubleshooting.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/dci-troubleshooting.md b/docs/dci-troubleshooting.md index 2c07f8e..e4b5fad 100644 --- a/docs/dci-troubleshooting.md +++ b/docs/dci-troubleshooting.md @@ -112,7 +112,7 @@ The error may also be thrown due to an encoding issue - changing to a UTF-8 serv Data Controller records timestamps (such as the SUBMITTED column on the Submitted screen, and the audit history) using the SAS session clock, via the `datetime()` function. That function returns the time of the operating system, adjusted by the [TIMEZONE= system option](https://documentation.sas.com/doc/en/pgmsascdc/default/lesysoptsref/p15siqs0s00e50n1wuuvygzkr14r.htm) if it is set. The value is then displayed in the frontend exactly as stored, without conversion. -On Viya, the SAS compute sessions that run Data Controller jobs are started inside Kubernetes containers whose clock is UTC by default, and which inherit no timezone from the host machine. If the TIMEZONE= option is not set for the compute context used by Data Controller, every timestamp DC records and displays is UTC. A customer in Germany (CEST, UTC+2 in summer) will therefore see submission times exactly 2 hours behind the wall clock. Other SAS products can appear unaffected because clients such as SAS Studio create their own compute sessions and pass the browser timezone / locale, whereas Data Controller submits jobs to its own shared compute context, which gets the raw container clock. +On Viya, the SAS compute sessions that run Data Controller jobs are started inside Kubernetes containers whose clock is UTC by default, and which inherit no timezone from the host machine. If the TIMEZONE= option is not set for the compute context used by Data Controller, every timestamp DC records and displays is UTC. A deployment in a UTC+2 timezone (such as CEST in summer) will therefore see submission times exactly 2 hours behind the wall clock. Other SAS products can appear unaffected because clients such as SAS Studio create their own compute sessions and pass the browser timezone / locale, whereas Data Controller submits jobs to its own shared compute context, which gets the raw container clock. To confirm the current state, run the following in a SAS session under the Data Controller compute context (or check the DC job log, where `_DEBUG` output shows the same values): @@ -137,7 +137,7 @@ Then recycle any existing compute sessions - hot sessions keep the old setting u Changing the timezone affects new timestamps only. Previously recorded submissions keep the UTC values that were stored when they were created. !!! warning - If you have downstream code that already converts DC timestamps from UTC to local time (for example a post-approve hook using `tzoneu2s(processed_dttm, 'Europe/Amsterdam')`), remove that conversion after applying the fix - otherwise the offset is applied twice and the times are wrong again. + If you have downstream code that already converts DC timestamps from UTC to local time (for example a post-approve hook that applies `tzoneu2s()` with a specific time zone), remove that conversion after applying the fix - otherwise the offset is applied twice and the times are wrong again. ## Determining Application Version