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