dc/docs.datacontroller.io
6
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: remove customer reference and conversion-function warning from timezone FAQ #4

Merged
hermes merged 1 commits from fix/timezone-docs-redact into main 2026-09-04 11:34:05 +00:00
Conversation 0 Commits 1 Files Changed 1
+1 -4
1 changed files with 1 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/dci-troubleshooting.md
+1 -4
View File
@@ -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 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.
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. 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):
@@ -136,9 +136,6 @@ Then recycle any existing compute sessions - hot sessions keep the old setting u
!!! note
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 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
The app version is bundled into the frontend during the release, and is visible by clicking your username in the top right.