From 8a59b6ee5fa6b6d210b8c7693e8c59ef2dd2bfc2 Mon Sep 17 00:00:00 2001 From: Pavel Antoshin Date: Fri, 10 Apr 2026 15:26:41 +0200 Subject: [PATCH 1/3] Documentation for DATEPARSE --- .../domain-model/oql/oql-expression-syntax.md | 46 +++++++++++++++++++ 1 file changed, 46 insertions(+) diff --git a/content/en/docs/refguide/modeling/domain-model/oql/oql-expression-syntax.md b/content/en/docs/refguide/modeling/domain-model/oql/oql-expression-syntax.md index 51b60ac6311..8cc2a6388f3 100644 --- a/content/en/docs/refguide/modeling/domain-model/oql/oql-expression-syntax.md +++ b/content/en/docs/refguide/modeling/domain-model/oql/oql-expression-syntax.md @@ -1022,6 +1022,52 @@ SELECT Revenue : DATEDIFF(MONTH, End, Start ) as avg_revenue FROM Sales.Period The way the difference is calculated depends on the database. The `YEAR` difference between "2002-01-01" and "2001-12-31" will be `1` with some databases and `0` with others. {{% /alert %}} +### DATEPARSE {#dateparse-function} + +The `DATEPARSE` function parses string values to Date and time using a specified pattern. + +This function was introduced in Mendix version 11.10.0. It is currently supported only in Java actions. + +#### Syntax + +The syntax is as follows: + +```sql +DATEPARSE ( expression , pattern ) +``` + +`expression` is a value of type String. + +`pattern` is a pattern used to convert `expression` to a Date and time value. Only string literals are allowed. + +#### Pattern syntax + +`DATEPARSE` OQL function uses the same pattern syntax as date parsing functions in Studio Pro, see [Parse and Format Date Function Calls](/refguide/parse-and-format-date-function-calls). + +#### Limitations and database-specific differences + +When an OQL query is executed, `DATEPARSE` is converted to the corresponding database function. Due to implementation specifics of database engines, different limitations apply: + +1. Format letters `u`, `F`, `G`, `k`, `K` are not supported. +2. Additionally, format letters `S` and `W` are not supported in MySQL and MariaDB. +3. For SQL Server, `DATEPARSE` accepts only patterns that match SQL Server styles 0 to 7, 9 to 13, 100 to 107, 109 to 113, 120 and 121. See [SQL Server documentation](https://learn.microsoft.com/en-us/sql/t-sql/functions/cast-and-convert-transact-sql?view=sql-server-ver17#date-and-time-styles) for the list of supported styles. +4. Format letter `h` accepts different ranges of values per database: + 1. HSQLDB accepts values `0` to `11` + 2. Other databases accept values `1` to `12` +5. In addition to listed limitations, there are other implementation differences between database engines. + +{{% alert color="warning" %}} +Always test usages of `DATEPARSE` with the database engine on which your app runs. OQL queries with `DATEPARSE` may return different results in HSQLDB and in the production database. +{{% /alert %}} + +#### Examples{#oql-dateparse-example} + +| Function call | Result | Notes | +|--------------|------|-----| +| `DATEPARSE('20 Mar 2026', 'dd MMM yyyy')` | 2026-03-20 00:00:00.000 | This format works for all databases. It matches SQL Server style 102. | +| `DATEPARSE('2026-03-20 14:30:45', 'yyyy-MM-dd HH:mm:ss')` | 2026-03-20 14:30:45.000 | This format works for all databases. It matches SQL Server style 120. | +| `DATEPARSE('20/03/2026 14:30:45.123', 'dd/MM/yyyy HH:mm:ss.SSS')` | 2026-03-20 14:30:45.123 | This format does not work in MySQL and MariaDB due to unsupported letter `S`. It does not work in SQL Server because there is no matching datetime style. | + ### DATEPART {#datepart-function} The `DATEPART` function retrieves a specified element from `DATETIME` values. The return type is `INTEGER`. From 821d37ccaa0f8282df0cb34d777a3d35ca83c15d Mon Sep 17 00:00:00 2001 From: MarkvanMents Date: Thu, 23 Apr 2026 16:54:14 +0200 Subject: [PATCH 2/3] Proofread --- .../domain-model/oql/oql-expression-syntax.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/content/en/docs/refguide/modeling/domain-model/oql/oql-expression-syntax.md b/content/en/docs/refguide/modeling/domain-model/oql/oql-expression-syntax.md index 8cc2a6388f3..17048ae7885 100644 --- a/content/en/docs/refguide/modeling/domain-model/oql/oql-expression-syntax.md +++ b/content/en/docs/refguide/modeling/domain-model/oql/oql-expression-syntax.md @@ -1040,20 +1040,22 @@ DATEPARSE ( expression , pattern ) `pattern` is a pattern used to convert `expression` to a Date and time value. Only string literals are allowed. -#### Pattern syntax +#### Pattern Syntax -`DATEPARSE` OQL function uses the same pattern syntax as date parsing functions in Studio Pro, see [Parse and Format Date Function Calls](/refguide/parse-and-format-date-function-calls). +The `DATEPARSE` OQL function uses the same pattern syntax as date parsing functions in Studio Pro, see [Parse and Format Date Function Calls](/refguide/parse-and-format-date-function-calls). -#### Limitations and database-specific differences +#### Limitations and Database-Specific Differences When an OQL query is executed, `DATEPARSE` is converted to the corresponding database function. Due to implementation specifics of database engines, different limitations apply: 1. Format letters `u`, `F`, `G`, `k`, `K` are not supported. -2. Additionally, format letters `S` and `W` are not supported in MySQL and MariaDB. +2. MySQL and MariaDB do not support format letters `S` and `W`. 3. For SQL Server, `DATEPARSE` accepts only patterns that match SQL Server styles 0 to 7, 9 to 13, 100 to 107, 109 to 113, 120 and 121. See [SQL Server documentation](https://learn.microsoft.com/en-us/sql/t-sql/functions/cast-and-convert-transact-sql?view=sql-server-ver17#date-and-time-styles) for the list of supported styles. 4. Format letter `h` accepts different ranges of values per database: - 1. HSQLDB accepts values `0` to `11` - 2. Other databases accept values `1` to `12` + + 1. HSQLDB accepts values `0` to `11` + 2. Other databases accept values `1` to `12` + 5. In addition to listed limitations, there are other implementation differences between database engines. {{% alert color="warning" %}} From c9fa9cb4e1d459222bacc3673f89d872178158f0 Mon Sep 17 00:00:00 2001 From: Pavel Antoshin <47475238+dahfjkg@users.noreply.github.com> Date: Fri, 24 Apr 2026 09:46:43 +0200 Subject: [PATCH 3/3] Update content/en/docs/refguide/modeling/domain-model/oql/oql-expression-syntax.md Co-authored-by: Mark van Ments <35492184+MarkvanMents@users.noreply.github.com> --- .../modeling/domain-model/oql/oql-expression-syntax.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/en/docs/refguide/modeling/domain-model/oql/oql-expression-syntax.md b/content/en/docs/refguide/modeling/domain-model/oql/oql-expression-syntax.md index 17048ae7885..5fcd3548dac 100644 --- a/content/en/docs/refguide/modeling/domain-model/oql/oql-expression-syntax.md +++ b/content/en/docs/refguide/modeling/domain-model/oql/oql-expression-syntax.md @@ -1053,8 +1053,8 @@ When an OQL query is executed, `DATEPARSE` is converted to the corresponding dat 3. For SQL Server, `DATEPARSE` accepts only patterns that match SQL Server styles 0 to 7, 9 to 13, 100 to 107, 109 to 113, 120 and 121. See [SQL Server documentation](https://learn.microsoft.com/en-us/sql/t-sql/functions/cast-and-convert-transact-sql?view=sql-server-ver17#date-and-time-styles) for the list of supported styles. 4. Format letter `h` accepts different ranges of values per database: - 1. HSQLDB accepts values `0` to `11` - 2. Other databases accept values `1` to `12` + 1. HSQLDB uses zero-based indexing and accepts values `0` to `11` + 2. Other databases use one-based indexing and accept values `1` to `12` 5. In addition to listed limitations, there are other implementation differences between database engines.