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.
If you still have questions, feel free to refer to our support team.
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.
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 |
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.
All the time zones in Time Zone Abbreviations - Worldwide List can be used as a value for a timezone when using the JWT DC expression parser.
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 | - |
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
If you still have questions, feel free to refer to our support team.
Powered by Atlassian Confluence 8.5.16, themed by Refined 7.6.0 and Decadis AG