You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+3-3Lines changed: 3 additions & 3 deletions
Original file line number
Diff line number
Diff line change
@@ -37,7 +37,7 @@ Let's explore an example of our schema for a typical JSON API response containin
37
37
}
38
38
}
39
39
```
40
-
In the above example, two types of constraint or rule descriptors are used: constraint functions (also known as validation functions, such as `@range(1, 10000)`) and constraint data types (also known as validation data types, such as `#integer`). All constraint functions begin with the `@` symbol, while all constraint data types start with `#`. C-style comments are also permitted in the schema. Please note that`address` can be `null` (eg. an optional input for users) and if it is `null` then no constraints of `address` are applicable. The following JSON is one of the examples which can successfully validate against the above schema. To start your journey with the JSON validation library, please consult the documentation available [here](https://relogiclabs.github.io/JsonSchema-Java/articles/intro).
40
+
In the above example, two types of constraints are used: constraint functions (also referred to as validation functions, such as `@range(1, 10000)`) and constraint data types (also referred to as validation data types, such as `#integer`). All constraint functions begin with the `@` symbol, while all constraint data types start with `#`. C-style comments are also supported within the schema. In this example,`address` can be `null` (like an optional input for users) and if it is `null` then no constraints of `address` are applicable. The following JSON is one of the examples that will be successfully validated against the above schema. To start your journey with the JSON validation library, please consult the documentation available [here](https://relogiclabs.github.io/JsonSchema-Java/articles/intro).
41
41
```json
42
42
{
43
43
"user": {
@@ -130,7 +130,7 @@ The next example represents an expanded version of the previous one, which bring
130
130
}
131
131
}
132
132
```
133
-
The subsequent JSON sample is an illustrative example that successfully validates against the expanded schema mentioned earlier. Within this example, recurring JSON structure appear that can be validated through defining components. By reusing defined components, you can achieve a clear and concise schema when validating large JSON with repetitive structures instead of duplicating large and complex validation constraints across the schema. This improves the overall readability and maintainability of the schema.
133
+
The subsequent JSON sample is an illustrative example that successfully validates against the expanded schema mentioned earlier. Within this example, recurring JSON structures appear that can be validated by defining components or nested functions and data types. Besides, reusing simple component definitions, you can achieve a clear and concise schema when validating large JSON with repetitive structures instead of duplicating or referring to various structures across the schema. This improves the overall readability and maintainability of the schema.
134
134
```json
135
135
{
136
136
"user": {
@@ -219,4 +219,4 @@ The subsequent JSON sample is an illustrative example that successfully validate
219
219
}
220
220
}
221
221
```
222
-
For more information about the schema syntax format and library functionalities, please refer to the reference documentation [here](https://relogiclabs.github.io/JsonSchema-Java/api/index.html).
222
+
For more information about the schema syntax format and library functionalities, please refer to the reference documentation [here](https://relogiclabs.github.io/JsonSchema-Java/api/index.html).
Copy file name to clipboardExpand all lines: doc/content/articles/datetime.md
+41-38Lines changed: 41 additions & 38 deletions
Original file line number
Diff line number
Diff line change
@@ -11,46 +11,49 @@ Date and time formats are defined using date and time pattern strings. Within th
11
11
12
12
Below, you will find a list of pattern letters and strings that are defined for date and time patterns. Please note that any characters within the 'A' to 'Z' and 'a' to 'z' range are reserved and should not be directly included in the pattern string.
| 17 |`ss`| Second in minute (2 digit form) |`01`; `30`|
33
+
| 18 |`s`| Second in minute (1-2 digit form) |`1`; `01`|
34
+
| 19 |`f`| Tenths of a second |`1`|
35
+
| 20 |`ff`| Hundredths of a second |`11`|
36
+
| 21 |`fff`| Milliseconds of a second |`111`|
37
+
| 22 |`ffff`| Ten thousandths of a second |`1111`|
38
+
| 23 |`fffff`| Hundred thousandths of a second |`11111`|
39
+
| 24 |`ffffff`| Millionths of a second |`111111`|
40
+
| 25 |`F`| Fraction of a second upto 6 digits |`1`; `111`; `111111`|
41
+
| 26 |`Z`| Time zone hours only offset |`+06`; `-05`; `Z`|
42
+
| 27 |`ZZ`| Time zone hours and minutes offset |`+09:30`; `−03:30`; `Z`|
43
+
| 28 |`ZZZ`| Time zone hours and minutes offset |`+0930`; `−0330`; `Z`|
41
44
42
45
The pattern components listed above can be combined to create comprehensive and customized date and time patterns to accommodate all system and user requirements. The following table illustrates some examples of how different date-time pattern components can be combined.
The first pattern in the table above adheres to the ISO 8601 date format and is used to validate the `#date` data type within the schema. The second pattern in the table follows the ISO 8601 format for date and time, validating the `#time` data type in the schema. Instead of explicitly specifying these patterns in the `@date` or `@time` functions, a more concise approach is to directly utilize the `#date` or `#time` type within the schema.
57
+
The first pattern in the table above adheres to the ISO 8601 date format and is used to validate the `#date` data type within the schema. The second pattern in the table follows the ISO 8601 format for date and time, validating the `#time` data type in the schema. Instead of explicitly specifying these patterns in the `@date` or `@time` functions, a more concise approach is to directly utilize the `#date` or `#time` type within the schema. Detailed explanations regarding the date and time format of the ISO 8601 standard are available in this [document](https://www.iso.org/iso-8601-date-and-time-format.html).
55
58
56
-
When the AM/PM designator is included in the date and time pattern, the presence of any hour format specifier indicates that the time is in the 12-hour clock format. Conversely, when the AM/PM designator is omitted, the presence of any hour format specifier indicates that the time is in the 24-hour clock format.
59
+
When the AM/PM designator is included in the date and time pattern, the presence of any hour format specifier indicates that the time is in the 12-hour clock format. Conversely, when the AM/PM designator is omitted, the presence of any hour format specifier indicates that the time is in the 24-hour clock format.
0 commit comments