From 9d1bf272c33b97966f225dd0c9ea7ceb2409b1c0 Mon Sep 17 00:00:00 2001 From: "J. Veldhuizen" Date: Tue, 5 Sep 2023 12:51:29 +0200 Subject: [PATCH 01/14] Update attributes with warning about non-localized dates and client UTC expressions --- .../refguide/modeling/domain-model/entities/attributes.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/en/docs/refguide/modeling/domain-model/entities/attributes.md b/content/en/docs/refguide/modeling/domain-model/entities/attributes.md index 62d60315a56..e10d274570c 100644 --- a/content/en/docs/refguide/modeling/domain-model/entities/attributes.md +++ b/content/en/docs/refguide/modeling/domain-model/entities/attributes.md @@ -130,9 +130,9 @@ A customer can be active or inactive, which is stored in an attribute named **Ac This property is shown if **Type** is set to **Date and time**. {{% /alert %}} -This property indicates whether the date and time should be localized. By default localization is enabled. If you are *not* interested in the time component of a date (for example, a birthday), you should set this property to 'No'. Otherwise, the date can change because of time zone differences: a date and time early in the morning on April 2nd in Europe will be on April 1st in the U.S.A. +This property indicates whether the date and time should be localized client-side. By default localization is enabled. If you are *not* interested in the time component of a date (for example, a birthday), you should set this property to 'No'. Otherwise, the date can change because of time zone differences: a date and time early in the morning on April 2nd in Europe will be on April 1st in the U.S.A. -In technical terms, this property indicates whether the client assumes that the date and time are in a local time zone (Yes) or in UTC (No). In the former case, the date is first converted to UTC before being sent to the server and converted from UTC before being displayed. +In technical terms, this property indicates whether the client assumes that the date and time are in a local time zone (Yes) or in UTC (No). In the former case, the date is first converted to UTC before being sent to the server and converted from UTC before being displayed. To avoid that this conversion is happening twice, UTC functions and tokens like [dateTimeUTC](/refguide/date-creation/) should not be used in client expressions to assign values to date and time attributes where localization is disabled. Default: *Yes* From 4bd6bc7401bb50fcce084291a928c6d14385f98a Mon Sep 17 00:00:00 2001 From: "J. Veldhuizen" Date: Tue, 5 Sep 2023 16:20:03 +0200 Subject: [PATCH 02/14] Clearify date-time localization in date and time handling document.md --- .../en/docs/refguide/runtime/date-and-time-handling/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/refguide/runtime/date-and-time-handling/_index.md b/content/en/docs/refguide/runtime/date-and-time-handling/_index.md index d32ab5f18a6..724a41537c0 100644 --- a/content/en/docs/refguide/runtime/date-and-time-handling/_index.md +++ b/content/en/docs/refguide/runtime/date-and-time-handling/_index.md @@ -63,7 +63,7 @@ If your application is accessible without signing in, those anonymous users will ## 6 To Localize or Not to Localize -Per attribute of type **Date and time** you can specify whether you want the date and time to be localized. This is not a new feature but worth mentioning on this page. Both localized and non-localized attributes are stored in UTC but only localized attributes are converted to the time zone of the user when displaying their value. Use non-localized attributes if you are not interested in the time component (for example, birthdays) or if you want a date to look exactly the same all over the world. +Per attribute of type **Date and time** you can specify whether you want the date and time to be localized client-side. This is not a new feature but worth mentioning on this page. Both localized and non-localized attributes are stored in UTC but only localized attributes are converted to the time zone of the user when displaying their value in the client. Use non-localized attributes if you are not interested in the time component (for example, birthdays) or if you want a date to look exactly the same all over the world. See the documentation of the Localize property of [Attributes](/refguide/attributes/) for more information. From efafb7a6d81335586745dd417ef29892fdc825da Mon Sep 17 00:00:00 2001 From: "J. Veldhuizen" Date: Tue, 5 Sep 2023 16:31:23 +0200 Subject: [PATCH 03/14] Update attributes.md --- .../docs/refguide/modeling/domain-model/entities/attributes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/refguide/modeling/domain-model/entities/attributes.md b/content/en/docs/refguide/modeling/domain-model/entities/attributes.md index e10d274570c..2dd949a3b3e 100644 --- a/content/en/docs/refguide/modeling/domain-model/entities/attributes.md +++ b/content/en/docs/refguide/modeling/domain-model/entities/attributes.md @@ -130,7 +130,7 @@ A customer can be active or inactive, which is stored in an attribute named **Ac This property is shown if **Type** is set to **Date and time**. {{% /alert %}} -This property indicates whether the date and time should be localized client-side. By default localization is enabled. If you are *not* interested in the time component of a date (for example, a birthday), you should set this property to 'No'. Otherwise, the date can change because of time zone differences: a date and time early in the morning on April 2nd in Europe will be on April 1st in the U.S.A. +This property indicates whether the date and time should be localized when displaying (or picking) their value. By default localization is enabled. If you are *not* interested in the time component of a date (for example, a birthday), you should set this property to 'No'. Otherwise, the date can change because of time zone differences: a date and time early in the morning on April 2nd in Europe will be on April 1st in the U.S.A. In technical terms, this property indicates whether the client assumes that the date and time are in a local time zone (Yes) or in UTC (No). In the former case, the date is first converted to UTC before being sent to the server and converted from UTC before being displayed. To avoid that this conversion is happening twice, UTC functions and tokens like [dateTimeUTC](/refguide/date-creation/) should not be used in client expressions to assign values to date and time attributes where localization is disabled. From cd0f84edd2af4d3e03aa6579d50b2eff008985c0 Mon Sep 17 00:00:00 2001 From: "J. Veldhuizen" Date: Tue, 5 Sep 2023 16:51:11 +0200 Subject: [PATCH 04/14] Update date-and-time-handling _index.md --- .../en/docs/refguide/runtime/date-and-time-handling/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/refguide/runtime/date-and-time-handling/_index.md b/content/en/docs/refguide/runtime/date-and-time-handling/_index.md index 724a41537c0..2d7ec7b22ee 100644 --- a/content/en/docs/refguide/runtime/date-and-time-handling/_index.md +++ b/content/en/docs/refguide/runtime/date-and-time-handling/_index.md @@ -63,7 +63,7 @@ If your application is accessible without signing in, those anonymous users will ## 6 To Localize or Not to Localize -Per attribute of type **Date and time** you can specify whether you want the date and time to be localized client-side. This is not a new feature but worth mentioning on this page. Both localized and non-localized attributes are stored in UTC but only localized attributes are converted to the time zone of the user when displaying their value in the client. Use non-localized attributes if you are not interested in the time component (for example, birthdays) or if you want a date to look exactly the same all over the world. +Per attribute of type **Date and time** you can specify whether you want the date and time to be localized when displaying (or picking) their value. This is not a new feature but worth mentioning on this page. Both localized and non-localized attributes are stored in UTC but only localized attributes are converted to the time zone of the user when displaying their value, for example in the client or in generated documents. Use non-localized attributes if you are not interested in the time component (for example, birthdays) or if you want a date to look exactly the same all over the world. See the documentation of the Localize property of [Attributes](/refguide/attributes/) for more information. From 30b52e4e005e460c134ff0022fa85f69fcdf97b7 Mon Sep 17 00:00:00 2001 From: "J. Veldhuizen" Date: Tue, 5 Sep 2023 17:41:02 +0200 Subject: [PATCH 05/14] Update date-creation with localization information --- .../modeling/application-logic/expressions/date-creation.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/content/en/docs/refguide/modeling/application-logic/expressions/date-creation.md b/content/en/docs/refguide/modeling/application-logic/expressions/date-creation.md index a94a62a1892..d7c89223cd4 100644 --- a/content/en/docs/refguide/modeling/application-logic/expressions/date-creation.md +++ b/content/en/docs/refguide/modeling/application-logic/expressions/date-creation.md @@ -9,6 +9,10 @@ tags: ["studio pro", "expression", "date creation", "expressions"] Dates can be created with the `dateTime` and `dateTimeUTC` functions. The difference between them is that `dateTime` uses the calendar of the session used in the function call, and `dateTimeUTC` uses the UTC calendar. The system session runs as UTC by default, except for scheduled events, which can be configured in the [Scheduled Event Time Zone](/refguide/app-settings/#scheduled) section of **App Settings**. +{{% alert color="info" %}} +Don't use `dateTimeUTC` in client-side expressions when you want to assign them to date and time attributes where Localize is set to No. The localize functionality is built into the attribute type itself and using the UTC functions causes timezone conversions to be handled twice. +{{% /alert %}} + This function does not accept variable or attribute parameters, only fixed values. To create a date using parameters, use the [parseDateTime](/refguide/parse-and-format-date-function-calls/#parsedatetime-utc) function. ## 2 Values From 60594703dcce45a85edeef3035b007d9a7790a65 Mon Sep 17 00:00:00 2001 From: "J. Veldhuizen" Date: Wed, 6 Sep 2023 08:32:49 +0200 Subject: [PATCH 06/14] Update parse-and-format-date-function-calls with non-localized info --- .../expressions/parse-and-format-date-function-calls.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/content/en/docs/refguide/modeling/application-logic/expressions/parse-and-format-date-function-calls.md b/content/en/docs/refguide/modeling/application-logic/expressions/parse-and-format-date-function-calls.md index c3e46679637..af2249dec14 100644 --- a/content/en/docs/refguide/modeling/application-logic/expressions/parse-and-format-date-function-calls.md +++ b/content/en/docs/refguide/modeling/application-logic/expressions/parse-and-format-date-function-calls.md @@ -53,6 +53,10 @@ The following pattern letters are only available for microflows: | Z | Time zone | -0800 | | X | Time zone | -08; -0800; -08:00 | +{{% alert color="info" %}} +For some parse and format functions, there are extra UTC variants. Don't use these UTC variants (like `parseDateTimeUTC`) in client-side expressions when you want to assign them to date and time attributes where Localize is set to No. The localize functionality is built into the attribute type itself and using the UTC functions causes timezone conversions to be handled twice. +{{% /alert %}} + ## 2 parseDateTime[UTC] {#parsedatetime-utc} Takes a string and parses it. If it fails and a default value is specified, it returns the default value. Otherwise, an error occurs. The function `parseDateTime` uses the user's time zone and `parseDateTimeUTC` uses the UTC calendar. From a3b582649e7111d0d69909a99bfc1cedd0d42a81 Mon Sep 17 00:00:00 2001 From: "J. Veldhuizen" Date: Wed, 6 Sep 2023 08:47:22 +0200 Subject: [PATCH 07/14] Update xpath-keywords-and-system-variables with non-localized info --- .../xpath-constraints/xpath-keywords-and-system-variables.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/content/en/docs/refguide/modeling/xpath/xpath-constraints/xpath-keywords-and-system-variables.md b/content/en/docs/refguide/modeling/xpath/xpath-constraints/xpath-keywords-and-system-variables.md index 4ba3522f472..27e191f9698 100644 --- a/content/en/docs/refguide/modeling/xpath/xpath-constraints/xpath-keywords-and-system-variables.md +++ b/content/en/docs/refguide/modeling/xpath/xpath-constraints/xpath-keywords-and-system-variables.md @@ -94,6 +94,10 @@ The following tokens can be used to obtain a date and time value: | `[%EndOfCurrentYear%]` | The date and time at the end of the current year. | | `[%EndOfCurrentYearUTC%]` | The date and time at the end of the current year in UTC. | +{{% alert color="info" %}} +Don't use the UTC variants of these tokens (like `[%BeginOfCurrentDayUTC%]`) in client-side expressions when you want to assign them to date and time attributes where Localize is set to No. The localize functionality is built into the attribute type itself and using the UTC functions causes timezone conversions to be handled twice. +{{% /alert %}} + The following tokens can be used to add or subtract a period of time from a date and time token value: | Token | Description | From e5ccc684426119bcaab8ec738a76f57e5551d8c4 Mon Sep 17 00:00:00 2001 From: "J. Veldhuizen" Date: Wed, 6 Sep 2023 09:13:28 +0200 Subject: [PATCH 08/14] Update xpath-keywords-and-system-variables.md --- .../xpath-constraints/xpath-keywords-and-system-variables.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/refguide/modeling/xpath/xpath-constraints/xpath-keywords-and-system-variables.md b/content/en/docs/refguide/modeling/xpath/xpath-constraints/xpath-keywords-and-system-variables.md index 27e191f9698..fca215b32ef 100644 --- a/content/en/docs/refguide/modeling/xpath/xpath-constraints/xpath-keywords-and-system-variables.md +++ b/content/en/docs/refguide/modeling/xpath/xpath-constraints/xpath-keywords-and-system-variables.md @@ -95,7 +95,7 @@ The following tokens can be used to obtain a date and time value: | `[%EndOfCurrentYearUTC%]` | The date and time at the end of the current year in UTC. | {{% alert color="info" %}} -Don't use the UTC variants of these tokens (like `[%BeginOfCurrentDayUTC%]`) in client-side expressions when you want to assign them to date and time attributes where Localize is set to No. The localize functionality is built into the attribute type itself and using the UTC functions causes timezone conversions to be handled twice. +Don't use the UTC variants of these tokens (like `[%BeginOfCurrentDayUTC%]`) in client-side expressions when you want to assign them or compare them to date and time attributes where Localize is set to No. The localize functionality is built into the attribute type itself and using the UTC functions causes timezone conversions to be handled twice. {{% /alert %}} The following tokens can be used to add or subtract a period of time from a date and time token value: From 85439834ce0acdff446e8906cc4d4df4db773cf4 Mon Sep 17 00:00:00 2001 From: "J. Veldhuizen" Date: Wed, 6 Sep 2023 09:14:09 +0200 Subject: [PATCH 09/14] Update date-creation.md --- .../modeling/application-logic/expressions/date-creation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/refguide/modeling/application-logic/expressions/date-creation.md b/content/en/docs/refguide/modeling/application-logic/expressions/date-creation.md index d7c89223cd4..9df86a77dd7 100644 --- a/content/en/docs/refguide/modeling/application-logic/expressions/date-creation.md +++ b/content/en/docs/refguide/modeling/application-logic/expressions/date-creation.md @@ -10,7 +10,7 @@ tags: ["studio pro", "expression", "date creation", "expressions"] Dates can be created with the `dateTime` and `dateTimeUTC` functions. The difference between them is that `dateTime` uses the calendar of the session used in the function call, and `dateTimeUTC` uses the UTC calendar. The system session runs as UTC by default, except for scheduled events, which can be configured in the [Scheduled Event Time Zone](/refguide/app-settings/#scheduled) section of **App Settings**. {{% alert color="info" %}} -Don't use `dateTimeUTC` in client-side expressions when you want to assign them to date and time attributes where Localize is set to No. The localize functionality is built into the attribute type itself and using the UTC functions causes timezone conversions to be handled twice. +Don't use `dateTimeUTC` in client-side expressions when you want to assign them or compare them to date and time attributes where Localize is set to No. The localize functionality is built into the attribute type itself and using the UTC functions causes timezone conversions to be handled twice. {{% /alert %}} This function does not accept variable or attribute parameters, only fixed values. To create a date using parameters, use the [parseDateTime](/refguide/parse-and-format-date-function-calls/#parsedatetime-utc) function. From c4c52e257f9eea3adeac30ea0993d43a0c2b5a20 Mon Sep 17 00:00:00 2001 From: "J. Veldhuizen" Date: Wed, 6 Sep 2023 09:15:44 +0200 Subject: [PATCH 10/14] Update parse-and-format-date-function-calls.md --- .../expressions/parse-and-format-date-function-calls.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/refguide/modeling/application-logic/expressions/parse-and-format-date-function-calls.md b/content/en/docs/refguide/modeling/application-logic/expressions/parse-and-format-date-function-calls.md index af2249dec14..fc66338109d 100644 --- a/content/en/docs/refguide/modeling/application-logic/expressions/parse-and-format-date-function-calls.md +++ b/content/en/docs/refguide/modeling/application-logic/expressions/parse-and-format-date-function-calls.md @@ -54,7 +54,7 @@ The following pattern letters are only available for microflows: | X | Time zone | -08; -0800; -08:00 | {{% alert color="info" %}} -For some parse and format functions, there are extra UTC variants. Don't use these UTC variants (like `parseDateTimeUTC`) in client-side expressions when you want to assign them to date and time attributes where Localize is set to No. The localize functionality is built into the attribute type itself and using the UTC functions causes timezone conversions to be handled twice. +For some parse and format functions, there are extra UTC variants. Don't use these UTC variants (like `parseDateTimeUTC`) in client-side expressions when you want to assign them or compare them to date and time attributes where Localize is set to No. The localize functionality is built into the attribute type itself and using the UTC functions causes timezone conversions to be handled twice. {{% /alert %}} ## 2 parseDateTime[UTC] {#parsedatetime-utc} From c14ce7075e2ec1d3f3ef23cdac3b9166a9e502cf Mon Sep 17 00:00:00 2001 From: Yiyun Liao Date: Mon, 11 Sep 2023 16:17:30 +0200 Subject: [PATCH 11/14] Language and style review --- .../application-logic/expressions/date-creation.md | 2 +- .../expressions/parse-and-format-date-function-calls.md | 2 +- .../refguide/modeling/domain-model/entities/attributes.md | 8 ++++---- .../xpath-keywords-and-system-variables.md | 2 +- .../refguide/runtime/date-and-time-handling/_index.md | 4 ++-- 5 files changed, 9 insertions(+), 9 deletions(-) diff --git a/content/en/docs/refguide/modeling/application-logic/expressions/date-creation.md b/content/en/docs/refguide/modeling/application-logic/expressions/date-creation.md index 9df86a77dd7..8a5e60d50c4 100644 --- a/content/en/docs/refguide/modeling/application-logic/expressions/date-creation.md +++ b/content/en/docs/refguide/modeling/application-logic/expressions/date-creation.md @@ -10,7 +10,7 @@ tags: ["studio pro", "expression", "date creation", "expressions"] Dates can be created with the `dateTime` and `dateTimeUTC` functions. The difference between them is that `dateTime` uses the calendar of the session used in the function call, and `dateTimeUTC` uses the UTC calendar. The system session runs as UTC by default, except for scheduled events, which can be configured in the [Scheduled Event Time Zone](/refguide/app-settings/#scheduled) section of **App Settings**. {{% alert color="info" %}} -Don't use `dateTimeUTC` in client-side expressions when you want to assign them or compare them to date and time attributes where Localize is set to No. The localize functionality is built into the attribute type itself and using the UTC functions causes timezone conversions to be handled twice. +Do not use `dateTimeUTC` in client-side expressions (for example, in nanoflows) if you want to assign the output to (or compare the output with) an attribute of type **Date and time** where **Localize** is disabled. In the client, the localization functionality is built into the attribute type itself, and using UTC functions causes the time zone conversion to be handled twice. {{% /alert %}} This function does not accept variable or attribute parameters, only fixed values. To create a date using parameters, use the [parseDateTime](/refguide/parse-and-format-date-function-calls/#parsedatetime-utc) function. diff --git a/content/en/docs/refguide/modeling/application-logic/expressions/parse-and-format-date-function-calls.md b/content/en/docs/refguide/modeling/application-logic/expressions/parse-and-format-date-function-calls.md index fc66338109d..cddcd1cc8e7 100644 --- a/content/en/docs/refguide/modeling/application-logic/expressions/parse-and-format-date-function-calls.md +++ b/content/en/docs/refguide/modeling/application-logic/expressions/parse-and-format-date-function-calls.md @@ -54,7 +54,7 @@ The following pattern letters are only available for microflows: | X | Time zone | -08; -0800; -08:00 | {{% alert color="info" %}} -For some parse and format functions, there are extra UTC variants. Don't use these UTC variants (like `parseDateTimeUTC`) in client-side expressions when you want to assign them or compare them to date and time attributes where Localize is set to No. The localize functionality is built into the attribute type itself and using the UTC functions causes timezone conversions to be handled twice. +For some parse and format functions, there are UTC variants. Do not use these UTC variants (for example, `parseDateTimeUTC`) in client-side expressions when you want to assign the output to (or compare the output with) an attribute of type **Date and time** where **Localize** is disabled. In the client, the localization functionality is built into the attribute type itself, and using UTC functions causes the time zone conversion to be handled twice. {{% /alert %}} ## 2 parseDateTime[UTC] {#parsedatetime-utc} diff --git a/content/en/docs/refguide/modeling/domain-model/entities/attributes.md b/content/en/docs/refguide/modeling/domain-model/entities/attributes.md index 2dd949a3b3e..3b9a2847313 100644 --- a/content/en/docs/refguide/modeling/domain-model/entities/attributes.md +++ b/content/en/docs/refguide/modeling/domain-model/entities/attributes.md @@ -124,17 +124,17 @@ A customer can be active or inactive, which is stored in an attribute named **Ac {{< figure src="/attachments/refguide/modeling/domain-model/entities/attributes/customer-attribute-examples.png" >}} -#### 2.2.2 Localize +#### 2.2.2 Localize {#localize} {{% alert color="info" %}} This property is shown if **Type** is set to **Date and time**. {{% /alert %}} -This property indicates whether the date and time should be localized when displaying (or picking) their value. By default localization is enabled. If you are *not* interested in the time component of a date (for example, a birthday), you should set this property to 'No'. Otherwise, the date can change because of time zone differences: a date and time early in the morning on April 2nd in Europe will be on April 1st in the U.S.A. +This property indicates whether the date and time should be localized when displaying (or picking) their value. By default localization is enabled. If you are NOT interested in the time component of a date (for example, a birthday), you should toggle this property off. Otherwise, the date can change because of time zone differences: a date and time early in the morning on April 2 in Europe will be on April 1 in the U.S.A. -In technical terms, this property indicates whether the client assumes that the date and time are in a local time zone (Yes) or in UTC (No). In the former case, the date is first converted to UTC before being sent to the server and converted from UTC before being displayed. To avoid that this conversion is happening twice, UTC functions and tokens like [dateTimeUTC](/refguide/date-creation/) should not be used in client expressions to assign values to date and time attributes where localization is disabled. +In technical terms, this property indicates whether the client assumes that the date and time are in a local time zone (Yes) or in UTC (No). In the former case, the date is first converted to UTC before being sent to the server and converted from UTC before being displayed. To avoid this time zone conversion from happening twice, UTC functions and tokens like [dateTimeUTC](/refguide/date-creation/) should not be used in client-side expressions to assign values to **Date and time** attributes where localization is disabled. -Default: *Yes* +Default: *enabled* #### 2.2.3 Enumeration diff --git a/content/en/docs/refguide/modeling/xpath/xpath-constraints/xpath-keywords-and-system-variables.md b/content/en/docs/refguide/modeling/xpath/xpath-constraints/xpath-keywords-and-system-variables.md index fca215b32ef..03764fb1f49 100644 --- a/content/en/docs/refguide/modeling/xpath/xpath-constraints/xpath-keywords-and-system-variables.md +++ b/content/en/docs/refguide/modeling/xpath/xpath-constraints/xpath-keywords-and-system-variables.md @@ -95,7 +95,7 @@ The following tokens can be used to obtain a date and time value: | `[%EndOfCurrentYearUTC%]` | The date and time at the end of the current year in UTC. | {{% alert color="info" %}} -Don't use the UTC variants of these tokens (like `[%BeginOfCurrentDayUTC%]`) in client-side expressions when you want to assign them or compare them to date and time attributes where Localize is set to No. The localize functionality is built into the attribute type itself and using the UTC functions causes timezone conversions to be handled twice. +Do not use the UTC variants of these tokens (for example, `[%BeginOfCurrentDayUTC%]`) in client-side expressions if you want to assign the output to (or compare the output with) an attribute of type **Date and Time** where **Localize** is disabled. In the client, the localization functionality is built into the attribute type itself, and using the UTC functions causes the time zone conversion to be handled twice. {{% /alert %}} The following tokens can be used to add or subtract a period of time from a date and time token value: diff --git a/content/en/docs/refguide/runtime/date-and-time-handling/_index.md b/content/en/docs/refguide/runtime/date-and-time-handling/_index.md index 2d7ec7b22ee..50e6addb5fe 100644 --- a/content/en/docs/refguide/runtime/date-and-time-handling/_index.md +++ b/content/en/docs/refguide/runtime/date-and-time-handling/_index.md @@ -63,9 +63,9 @@ If your application is accessible without signing in, those anonymous users will ## 6 To Localize or Not to Localize -Per attribute of type **Date and time** you can specify whether you want the date and time to be localized when displaying (or picking) their value. This is not a new feature but worth mentioning on this page. Both localized and non-localized attributes are stored in UTC but only localized attributes are converted to the time zone of the user when displaying their value, for example in the client or in generated documents. Use non-localized attributes if you are not interested in the time component (for example, birthdays) or if you want a date to look exactly the same all over the world. +Per attribute of type **Date and time** you can specify whether you want the date and time to be localized when displaying (or picking) their value. This is not a new feature but worth mentioning on this page. Both localized and non-localized attributes are stored in UTC but only localized attributes are converted to the time zone of the user when displaying their value (for example, in the client or in generated documents). Use non-localized attributes if you are not interested in the time component of a date (for example, a birthday). -See the documentation of the Localize property of [Attributes](/refguide/attributes/) for more information. +For more information, see the [Localize](/refguide/attributes/#localize) section in *Attributes*. ## 7 Tokens From 1bf98f601d685925796a31cd69ab7c3c7bcd52df Mon Sep 17 00:00:00 2001 From: Yiyun Liao Date: Mon, 11 Sep 2023 16:26:23 +0200 Subject: [PATCH 12/14] Add the extra clarification sentence back --- .../docs/refguide/modeling/domain-model/entities/attributes.md | 2 +- .../en/docs/refguide/runtime/date-and-time-handling/_index.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/content/en/docs/refguide/modeling/domain-model/entities/attributes.md b/content/en/docs/refguide/modeling/domain-model/entities/attributes.md index 3b9a2847313..57c83145d18 100644 --- a/content/en/docs/refguide/modeling/domain-model/entities/attributes.md +++ b/content/en/docs/refguide/modeling/domain-model/entities/attributes.md @@ -130,7 +130,7 @@ A customer can be active or inactive, which is stored in an attribute named **Ac This property is shown if **Type** is set to **Date and time**. {{% /alert %}} -This property indicates whether the date and time should be localized when displaying (or picking) their value. By default localization is enabled. If you are NOT interested in the time component of a date (for example, a birthday), you should toggle this property off. Otherwise, the date can change because of time zone differences: a date and time early in the morning on April 2 in Europe will be on April 1 in the U.S.A. +This property indicates whether the date and time should be localized when displaying (or picking) their value. By default localization is enabled. If you are NOT interested in the time component of a date and you want the date to be exactly the same all over the world (for example, a birthday), you should toggle this property off. Otherwise, the date can change because of time zone differences: a date and time early in the morning on April 2 in Europe will be on April 1 in the U.S.A. In technical terms, this property indicates whether the client assumes that the date and time are in a local time zone (Yes) or in UTC (No). In the former case, the date is first converted to UTC before being sent to the server and converted from UTC before being displayed. To avoid this time zone conversion from happening twice, UTC functions and tokens like [dateTimeUTC](/refguide/date-creation/) should not be used in client-side expressions to assign values to **Date and time** attributes where localization is disabled. diff --git a/content/en/docs/refguide/runtime/date-and-time-handling/_index.md b/content/en/docs/refguide/runtime/date-and-time-handling/_index.md index 50e6addb5fe..87626eae8e0 100644 --- a/content/en/docs/refguide/runtime/date-and-time-handling/_index.md +++ b/content/en/docs/refguide/runtime/date-and-time-handling/_index.md @@ -63,7 +63,7 @@ If your application is accessible without signing in, those anonymous users will ## 6 To Localize or Not to Localize -Per attribute of type **Date and time** you can specify whether you want the date and time to be localized when displaying (or picking) their value. This is not a new feature but worth mentioning on this page. Both localized and non-localized attributes are stored in UTC but only localized attributes are converted to the time zone of the user when displaying their value (for example, in the client or in generated documents). Use non-localized attributes if you are not interested in the time component of a date (for example, a birthday). +Per attribute of type **Date and time** you can specify whether you want the date and time to be localized when displaying (or picking) their value. This is not a new feature but worth mentioning on this page. Both localized and non-localized attributes are stored in UTC but only localized attributes are converted to the time zone of the user when displaying their value (for example, in the client or in generated documents). Use non-localized attributes if you are not interested in the time component of a date and you want the date to be exactly the same all over the world (for example, a birthday). For more information, see the [Localize](/refguide/attributes/#localize) section in *Attributes*. From 9661906947b2ce980c57a1118fafaae4797daac0 Mon Sep 17 00:00:00 2001 From: Yiyun Liao Date: Mon, 11 Sep 2023 16:30:52 +0200 Subject: [PATCH 13/14] Small fixes --- .../expressions/parse-and-format-date-function-calls.md | 2 +- .../xpath-constraints/xpath-keywords-and-system-variables.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/content/en/docs/refguide/modeling/application-logic/expressions/parse-and-format-date-function-calls.md b/content/en/docs/refguide/modeling/application-logic/expressions/parse-and-format-date-function-calls.md index cddcd1cc8e7..abcbec00cc0 100644 --- a/content/en/docs/refguide/modeling/application-logic/expressions/parse-and-format-date-function-calls.md +++ b/content/en/docs/refguide/modeling/application-logic/expressions/parse-and-format-date-function-calls.md @@ -54,7 +54,7 @@ The following pattern letters are only available for microflows: | X | Time zone | -08; -0800; -08:00 | {{% alert color="info" %}} -For some parse and format functions, there are UTC variants. Do not use these UTC variants (for example, `parseDateTimeUTC`) in client-side expressions when you want to assign the output to (or compare the output with) an attribute of type **Date and time** where **Localize** is disabled. In the client, the localization functionality is built into the attribute type itself, and using UTC functions causes the time zone conversion to be handled twice. +For some parse and format functions, there are UTC variants. Do not use these UTC variants (for example, `parseDateTimeUTC`) in client-side expressions if you want to assign the output to (or compare the output with) an attribute of type **Date and time** where **Localize** is disabled. In the client, the localization functionality is built into the attribute type itself, and using UTC functions causes the time zone conversion to be handled twice. {{% /alert %}} ## 2 parseDateTime[UTC] {#parsedatetime-utc} diff --git a/content/en/docs/refguide/modeling/xpath/xpath-constraints/xpath-keywords-and-system-variables.md b/content/en/docs/refguide/modeling/xpath/xpath-constraints/xpath-keywords-and-system-variables.md index 03764fb1f49..e79b8957dfd 100644 --- a/content/en/docs/refguide/modeling/xpath/xpath-constraints/xpath-keywords-and-system-variables.md +++ b/content/en/docs/refguide/modeling/xpath/xpath-constraints/xpath-keywords-and-system-variables.md @@ -95,7 +95,7 @@ The following tokens can be used to obtain a date and time value: | `[%EndOfCurrentYearUTC%]` | The date and time at the end of the current year in UTC. | {{% alert color="info" %}} -Do not use the UTC variants of these tokens (for example, `[%BeginOfCurrentDayUTC%]`) in client-side expressions if you want to assign the output to (or compare the output with) an attribute of type **Date and Time** where **Localize** is disabled. In the client, the localization functionality is built into the attribute type itself, and using the UTC functions causes the time zone conversion to be handled twice. +Do not use the UTC variants of these tokens (for example, `[%BeginOfCurrentDayUTC%]`) in client-side expressions if you want to assign the output to (or compare the output with) an attribute of type **Date and time** where **Localize** is disabled. In the client, the localization functionality is built into the attribute type itself, and using UTC functions causes the time zone conversion to be handled twice. {{% /alert %}} The following tokens can be used to add or subtract a period of time from a date and time token value: From 75a26af95b28d624166669e8f5677874868ddb78 Mon Sep 17 00:00:00 2001 From: "J. Veldhuizen" Date: Tue, 12 Sep 2023 10:29:26 +0200 Subject: [PATCH 14/14] Use another enabled/disabled on Attributes page --- .../docs/refguide/modeling/domain-model/entities/attributes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/refguide/modeling/domain-model/entities/attributes.md b/content/en/docs/refguide/modeling/domain-model/entities/attributes.md index 57c83145d18..017ad1d02ef 100644 --- a/content/en/docs/refguide/modeling/domain-model/entities/attributes.md +++ b/content/en/docs/refguide/modeling/domain-model/entities/attributes.md @@ -132,7 +132,7 @@ This property is shown if **Type** is set to **Date and time**. This property indicates whether the date and time should be localized when displaying (or picking) their value. By default localization is enabled. If you are NOT interested in the time component of a date and you want the date to be exactly the same all over the world (for example, a birthday), you should toggle this property off. Otherwise, the date can change because of time zone differences: a date and time early in the morning on April 2 in Europe will be on April 1 in the U.S.A. -In technical terms, this property indicates whether the client assumes that the date and time are in a local time zone (Yes) or in UTC (No). In the former case, the date is first converted to UTC before being sent to the server and converted from UTC before being displayed. To avoid this time zone conversion from happening twice, UTC functions and tokens like [dateTimeUTC](/refguide/date-creation/) should not be used in client-side expressions to assign values to **Date and time** attributes where localization is disabled. +In technical terms, this property indicates whether the client assumes that the date and time are in a local time zone (enabled) or in UTC (disabled). In the former case, the date is first converted to UTC before being sent to the server and converted from UTC before being displayed. To avoid this time zone conversion from happening twice, UTC functions and tokens like [dateTimeUTC](/refguide/date-creation/) should not be used in client-side expressions to assign values to **Date and time** attributes where localization is disabled. Default: *enabled*