Author SHA1 Message Date
hermes 94b27628aa Merge pull request 'docs: remove customer reference and conversion-function warning from timezone FAQ' (#4) from fix/timezone-docs-redact into main
Publish to docs.datacontroller.io / Deploy docs (push) Successful in 1m12s
2026-09-04 11:34:05 +00:00
dc-bot 5236b74fee docs: remove customer reference and conversion-function warning from timezone FAQ 2026-09-04 11:33:49 +00:00
hermes 06df7e6e23 Merge pull request 'docs: remove customer-identifying details from timezone troubleshooting section' (#3) from fix/timezone-docs-redact into main
Publish to docs.datacontroller.io / Deploy docs (push) Failing after 13m6s
2026-09-04 10:21:03 +00:00
dc-bot 7e49033aae docs: remove customer-identifying details from timezone troubleshooting section 2026-09-04 10:20:08 +00:00
dc-bot 76bdc90ed8 docs: add troubleshooting section for timestamps displayed in UTC (compute context TIMEZONE)
Publish to docs.datacontroller.io / Deploy docs (push) Successful in 17m7s
2026-09-04 10:00:58 +00:00
allan 6782b77e69 Merge pull request 'docs: document v7.13.0 features' (#2) from docs/v7.13-features into main
Publish to docs.datacontroller.io / Deploy docs (push) Successful in 1m26s
Reviewed-on: #2
2026-09-03 20:11:49 +00:00
+28
View File
@@ -108,6 +108,34 @@ This can happen if you enter the wrong `serverName` when deploying the SAS progr
The error may also be thrown due to an encoding issue - changing to a UTF-8 server has helped at least one customer.
## Displayed timestamps are in UTC (or the wrong timezone)
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. 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):
```sas
proc options option=timezone;
run;
%put &=SYSTIMEZONEIDENT &=SYSTIMEZONEOFFSET;
```
If TIMEZONE is blank (and SYSTIMEZONEOFFSET is 0), the session is on UTC. To fix it, ask your Viya administrator to set the timezone for the compute context used by Data Controller (in SAS Environment Manager, edit the context's Autoexec, or set the context's SAS options):
```sas
options timezone='Europe/Berlin';
```
Then recycle any existing compute sessions - hot sessions keep the old setting until they terminate.
!!! note
Use a region/area time zone ID such as `Europe/Berlin` rather than a fixed offset such as `GMT+2`. Fixed offsets do not follow daylight saving time, so the display would be 1 hour off in winter (CET = UTC+1).
!!! note
Changing the timezone affects new timestamps only. Previously recorded submissions keep the UTC values that were stored when they were created.
## 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.