Show case timestamps in the correct time zone in templates

Updated Wednesday, October 28, 2026 · Marc Staine

A customer update can be technically correct and still cause confusion if two teams read its time in different zones. Supportbench case variables can format the activity-created, case-created and case-closure timestamps in a specified time zone. This is useful for regional customer teams, coordinated incident reviews and support handoffs. Choose the zone explicitly and explain it in the message; do not assume the recipient, agent and account all use the same local time.

At a glance

For: support operations teams and administrators writing case replies and workflow notifications. Applies to: Supportbench Core.

Start here: Settings → Cases → Templates → open a template → Content

Use a complete date token and numeric zone ID · Understand the output before promising a time · Choose a zone for the audience and purpose · Add a zoned timestamp to a case template · Verify against a known timestamp · Troubleshoot incorrect or missing time output · Complete Core time-zone ID mapping

Use a complete date token and numeric zone ID

The format is {{date_token | zone_id}}. Replace date_token with one of the three supported names below and zone_id with a number from the mapping. Keep the two opening braces, the vertical bar and the two closing braces. Do not type the words date_token or zone_id into your real template.

Supported example	Timestamp it formats
`{{case_created_on \| 10}}`	When the case was created, using zone 10 (Pacific Standard Time).
`{{activity_created_on \| 21}}`	The existing activity in the notification context, using zone 21 (Eastern Standard Time). In the case-list reply path, translation runs before the new reply exists, so this value is blank.
`{{case_closed_on \| 46}}`	The stored case closure value, using zone 46 (UTC). Check case status: a scheduled closure value is not proof that closure has already occurred.

This numeric form belongs to supported case-template translation. It is not a general date-format command for portal Liquid, survey campaigns or arbitrary text fields. Use the relevant feature’s guide when working outside a case message.

Understand the output before promising a time

Core converts the source UTC timestamp using the selected zone’s time rules and produces a value in the format MMM-dd-yyyy at hh:mm tt, followed by the Windows time-zone identifier. For example, if the source timestamp is exactly 28 October 2026 at 18:00 UTC, {{case_created_on | 46}} produces Oct-28-2026 at 06:00 PM UTC. This is an illustrative timestamp, not a value from your customer records.

A plain date token without the numbered zone, such as {{case_created_on}}, uses the UTC representation in this case translation. A missing timestamp becomes an empty string. The variable reports a recorded timestamp; it does not calculate the next response deadline, book an appointment or change an SLA.

The label “Standard Time” does not mean a fixed winter offset

Names such as Pacific Standard Time and Eastern Standard Time are zone identifiers. Conversion uses the zone’s applicable daylight-saving rules for the date, while the output still displays that identifier. Do not interpret the words “Standard Time” as a promise that the result uses a fixed offset, and do not replace them with a seasonal abbreviation without checking the actual date.

Choose a zone for the audience and purpose

Situation	Useful approach
A local customer operations team	Agree which regional zone the team uses, then choose its exact mapping. Make the zone clear in the surrounding message.
A multinational incident review	Consider UTC as the common reference so teams can compare timestamps consistently. State that decision in the review.
Two regions with similar abbreviations	Use the exact zone identifier; a short abbreviation can be ambiguous.
A customer changes offices or daylight-saving policy changes	Review the intended zone and test representative dates again. Do not keep a copied fixed offset as your rule.
The customer wants a future callback time	Record and communicate the actual agreed callback through the appropriate case/calendar procedure. These variables format stored case/activity dates; they do not schedule the callback.

Common choices include 10 for Pacific Standard Time, 21 for Eastern Standard Time and 46 for UTC. These examples are not recommendations for every customer. The full mapping below distinguishes zones that can share an offset today but follow different rules at another time of year.

Add a zoned timestamp to a case template

Confirm you can edit the intended case template and have an approved test case and recipient. Global templates require the appropriate additional permission.
Open Settings → Cases → Templates, open the template and select Content.
Place the cursor in the sentence where the timestamp should appear. Use the editor’s Variables menu to insert the relevant date token, or type the exact supported form.
Add the vertical bar and the required numeric ID inside the braces. For example: Request received: {{case_created_on | 21}}. Use the mapping below to verify the number.
Check that the sentence describes the selected timestamp accurately. “Request received” may suit case creation; “Resolved” must not be inferred merely from a populated closure field.
Save the template and reopen it to confirm the exact token was retained. Apply it through the intended case reply or workflow route.
Complete the controlled send and verification below. Seeing the literal token in the editor is not the final rendered-message test.

Verify against a known timestamp

Choose an approved test case whose actual source timestamp you can establish in UTC. Record the source value, selected numeric ID and expected zone.
Send through the same supported case reply/workflow path that will be used operationally. Review the resulting activity and received message; successful submission is not proof of delivery.
Confirm the output contains a real date/time and the intended zone identifier, with no unresolved braces. Compare it with the known source timestamp converted for that specific date.
For a zone that observes daylight saving, test representative dates on both sides of its seasonal change when relevant to your templates. Do not compare every date with one fixed offset.
Test a case without the optional timestamp, especially a closure value. Confirm the remaining sentence is still understandable or remove the sentence from a template used before closure.
Test the customer’s interpretation as well as the number: ask a colleague to identify the date, time and zone from the message without an explanation.

For a multi-region handoff, use a sentence such as “Case created (UTC): {{case_created_on | 46}}.” Keep a separate, explicit sentence for the next agreed customer update. A historical creation time should not look like a new service commitment.

Troubleshoot incorrect or missing time output

Symptom	Check and corrective step
The token stays visible	Check the supported template context, exact lower-case date-token name, braces, vertical bar and numeric ID. Test the send path rather than only the editor.
The send fails after adding a date token	An unsupported variable or unmapped ID can be rejected by a strict case translator. Replace it with a supported form and repeat a controlled test.
The output is blank	The relevant source timestamp may be missing. In case-list replies the new activity does not yet exist at translation, so activity-created time is blank. Confirm whether you selected activity-created, case-created or closure time. Do not substitute today’s date as if it were the missing historical value.
The time is one hour different from an old reference	Check daylight saving for the actual date and the selected zone. The historical fixed-offset table is not a reliable conversion reference.
The output says Standard Time during summer	That is the stable Windows zone identifier. Verify the converted time using that zone’s date-specific rules.
The message reports a future closed-on time	Check whether the case has a scheduled closure and review its current status. Reword the message instead of claiming it has already closed.
The agent’s calendar still shows another zone	This variable changes the text produced for this message. It does not change account, calendar, SLA or recipient time-zone preferences.
The chosen city is not named in the mapping	Ask the administrator which supported Windows zone corresponds to the intended region. Do not pick another city merely because its current offset matches.

Complete Core time-zone ID mapping

Use the numeric ID in the template. The names below are copied from Core’s supported mapping; they are not a table of permanent UTC offsets. Some names are historical Windows identifiers. Applicable time rules depend on the zone data used by the service, so validate date-sensitive output after relevant platform or regional time-rule changes.

ID	Windows time-zone identifier
1	Dateline Standard Time
2	UTC-11
3	Aleutian Standard Time
4	Hawaiian Standard Time
5	Marquesas Standard Time
6	Alaskan Standard Time
7	UTC-09
8	Pacific Standard Time (Mexico)
9	UTC-08
10	Pacific Standard Time
11	US Mountain Standard Time
12	Mountain Standard Time (Mexico)
13	Mountain Standard Time
14	Central America Standard Time
15	Central Standard Time
16	Easter Island Standard Time
17	Central Standard Time (Mexico)
18	Canada Central Standard Time
19	SA Pacific Standard Time
20	Eastern Standard Time (Mexico)
21	Eastern Standard Time
22	Haiti Standard Time
23	Cuba Standard Time
24	US Eastern Standard Time
25	Paraguay Standard Time
26	Atlantic Standard Time
27	Venezuela Standard Time
28	Central Brazilian Standard Time
29	SA Western Standard Time
30	Pacific SA Standard Time
31	Turks And Caicos Standard Time
32	Newfoundland Standard Time
33	Tocantins Standard Time
34	E. South America Standard Time
35	SA Eastern Standard Time
36	Argentina Standard Time
37	Greenland Standard Time
38	Montevideo Standard Time
39	Magallanes Standard Time
40	Saint Pierre Standard Time
41	Bahia Standard Time
42	UTC-02
43	Mid-Atlantic Standard Time
44	Azores Standard Time
45	Cape Verde Standard Time
46	UTC
47	Morocco Standard Time
48	GMT Standard Time
49	Greenwich Standard Time
50	W. Europe Standard Time
51	Central Europe Standard Time
52	Romance Standard Time
53	Central European Standard Time
54	W. Central Africa Standard Time
55	Namibia Standard Time
56	Jordan Standard Time
57	GTB Standard Time
58	Middle East Standard Time
59	Egypt Standard Time
60	E. Europe Standard Time
61	Syria Standard Time
62	West Bank Standard Time
63	South Africa Standard Time
64	FLE Standard Time
65	Israel Standard Time
66	Kaliningrad Standard Time
67	Libya Standard Time
68	Arabic Standard Time
69	Turkey Standard Time
70	Arab Standard Time
71	Belarus Standard Time
72	Russian Standard Time
73	E. Africa Standard Time
74	Iran Standard Time
75	Arabian Standard Time
76	Astrakhan Standard Time
77	Azerbaijan Standard Time
78	Russia Time Zone 3
79	Mauritius Standard Time
80	Saratov Standard Time
81	Georgian Standard Time
82	Caucasus Standard Time
83	Afghanistan Standard Time
84	West Asia Standard Time
85	Ekaterinburg Standard Time
86	Pakistan Standard Time
87	India Standard Time
88	Sri Lanka Standard Time
89	Nepal Standard Time
90	Central Asia Standard Time
91	Bangladesh Standard Time
92	Omsk Standard Time
93	Myanmar Standard Time
94	SE Asia Standard Time
95	Altai Standard Time
96	W. Mongolia Standard Time
97	North Asia Standard Time
98	N. Central Asia Standard Time
99	Tomsk Standard Time
100	China Standard Time
101	North Asia East Standard Time
102	Singapore Standard Time
103	W. Australia Standard Time
104	Taipei Standard Time
105	Ulaanbaatar Standard Time
106	North Korea Standard Time
107	Aus Central W. Standard Time
108	Transbaikal Standard Time
109	Tokyo Standard Time
110	Korea Standard Time
111	Yakutsk Standard Time
112	Cen. Australia Standard Time
113	AUS Central Standard Time
114	E. Australia Standard Time
115	AUS Eastern Standard Time
116	West Pacific Standard Time
117	Tasmania Standard Time
118	Vladivostok Standard Time
119	Lord Howe Standard Time
120	Bougainville Standard Time
121	Russia Time Zone 10
122	Magadan Standard Time
123	Norfolk Standard Time
124	Sakhalin Standard Time
125	Central Pacific Standard Time
126	Russia Time Zone 11
127	New Zealand Standard Time
128	UTC+12
129	Fiji Standard Time
130	Kamchatka Standard Time
131	Chatham Islands Standard Time
132	UTC+13
133	Tonga Standard Time
134	Samoa Standard Time
135	Line Islands Standard Time

Was this article helpful?