The table below shows which JWT DC parser functions can be mapped to JWT Cloud parser functions, and what needs to be taken into account when doing so.
Time Macros
JWT DC offers Time Macros for accessing date and time values like {SUNDAY} for the number of this day in the week (=7). The notion is a "macro", i.e. those keywords are enclosed in {}. In the JWT Cloud expression parser, they are noted as constants without curly brackets.
JWT DC
Mapping
JWT Cloud
{SECOND}
{MINUTE}
{HOUR}
{DAY}
{WEEK}
{MONTH}
{YEAR}
✅
✅
✅
✅
✅
✅
✅
SECOND
MINUTE
HOUR
DAY
WEEK
MONTH
YEAR
{SUNDAY}
{MONDAY}
{TUESDAY}
{WEDNESDAY}
{THURSDAY}
{FRIDAY}
{SATURDAY}
✅
✅
✅
✅
✅
✅
✅
SUNDAY
MONDAY
TUESDAY
WEDNESDAY
THURSDAY
FRIDAY
SATURDAY
{JANUARY}
{FEBRUARY}
{MARCH}
{APRIL}
{MAY}
{JUNE}
{JULY}
{AUGUST}
{SEPTEMBER}
{OCTOBER}
{NOVEMBER}
{DECEMBER}
✅
✅
✅
✅
✅
✅
✅
✅
✅
✅
✅
✅
JANUARY
FEBRUARY
MARCH
APRIL
MAY
JUNE
JULY
AUGUST
SEPTEMBER
OCTOBER
NOVEMBER
DECEMBER
Time Zones
The JWT DC expression parser offers a couple of time zones which can be used as time zone parameter for the parser functions described in Dates, times and time zones.
The JWT Cloud expression parser relies on the List of tz database time zones, column "TZ database name". It has to be quoted when used as a parameter in a JWT Cloud parser function.
Using these kind of timezone names is especially useful, if you relate to a region with daylight savings time (DST), since this behavior is covered as well, while for timezone abbreviations, the user has to set, e.g. CET or CEST.
Timezone abbreviations may also be ambiguous, like e.g. "CST", which stands for Central Standard time (UTC-6), Cuba Standard Time (UTC-5), and also China Standard Time (UTC+8).
Fortunately, the JWT DC parser function timeZone() accepts the same kind of parameter like JWT Cloud, e.g. "Pacific/Auckland", so you may also want to update your JWT DC parser function call accordingly.
If you are using a time zone abbreviation in JWT DC, you have to map it to the timezone in JWT Cloud by using Time Zone Abbreviations - Worldwide List as source and List of tz database time zones as target. If there are several alternatives, the best way is to select a timezone which has the same UTC offset as the one in JWT DC.
Examples:
Timezone
UTC offset
JWT DC
JWT Cloud
Coordinated Universal Time
+00:00
UTC
"UTC"
Central Standard Time
-06:00
CST
"US/Central"
Singapore
+08:00
SGT
"Singapore"
This table shows how the constants for timezones in JWT DC can be mapped to JWT Cloud.
JWT DC
Mapping
JWT Cloud
LOCAL
-
RUN_AS_LOCAL
✅
RUN_AS_LOCAL
SERVER_LOCAL
-
Languages
This table shows how the constants for languages in JWT DC can be mapped to JWT Cloud.
JWT DC
Mapping
JWT Cloud
RUN_AS_LANG
✅
RUN_AS_LANG
SERVER_LANG
-
USER_LANG
-
JWT Cloud offers the option of using most common ISO 639-1 Codes, like the two-letter version "en", or the four-letter version "en-gb" etc.. The string is not case sensitive, so "EN" is valid as well. You don't have to use the hyphen(-), an underscore will work as well, i.e. "en-gb" is equivalent to "en_GB". If the language is not available (e.g. "english"), an error is returned.
These locales may be used instead of SERVER_LANG or USER_LANG
While the timeZone() function itself is not supported in JWT Cloud, you can simply replace the function call with its text parameter, if it represents a valid "TZ database name" ( see JWT Cloud Time zones).
E.g. just replace timePart({issue.created}, timeZone("Pacific/Auckland")) by timePart({issue.created}, "Pacific/Auckland")
JWT DC
JWT Cloud