@ama-sdk/schematics 11.4.0-prerelease.18 → 11.4.0-prerelease.19

package/README.md

@@ -132,6 +132,10 @@ If your specification file includes dates, there are multiple options for the ge
   For more information related to these types, check out this [documentation](https://github.com/AmadeusITGroup/otter/tree/main/packages/%40ama-sdk/schematics/schematics/typescript/shell/templates/base#manage-dates).
   This can be done by adding `--global-property stringifyDate=false` to the generator command or by adding the global property
 to the `openapitools.json`.
+> [!NOTE]
+> An extra type to manage special timezone use cases can be used at property level thanks to the
+> `x-local-timezone` vendor. 
+> Please check out the [date documentation](https://github.com/AmadeusITGroup/otter/tree/main/packages/%40ama-sdk/schematics/schematics/typescript/shell/templates/base#manage-dates).
 
 Example to use `Date`:
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ama-sdk/schematics",
-  "version": "11.4.0-prerelease.18",
+  "version": "11.4.0-prerelease.19",
   "publishConfig": {
     "access": "public"
   },
@@ -57,12 +57,12 @@
     }
   },
   "peerDependencies": {
-    "@ama-sdk/core": "^11.4.0-prerelease.18",
+    "@ama-sdk/core": "^11.4.0-prerelease.19",
     "@angular-devkit/core": "~18.2.0",
     "@angular-devkit/schematics": "~18.2.0",
     "@angular-devkit/schematics-cli": "^18.0.5",
     "@angular/cli": "~18.2.0",
-    "@o3r/schematics": "^11.4.0-prerelease.18",
+    "@o3r/schematics": "^11.4.0-prerelease.19",
     "@openapitools/openapi-generator-cli": "~2.13.0",
     "@schematics/angular": "~18.2.0"
   },
@@ -79,17 +79,17 @@
     "tslib": "^2.6.2"
   },
   "devDependencies": {
-    "@ama-sdk/core": "^11.4.0-prerelease.18",
+    "@ama-sdk/core": "^11.4.0-prerelease.19",
     "@angular-devkit/schematics-cli": "^18.0.5",
     "@angular-eslint/eslint-plugin": "~18.3.0",
     "@angular/cli": "~18.2.0",
     "@nx/eslint-plugin": "~19.5.0",
     "@nx/jest": "~19.5.0",
-    "@o3r/build-helpers": "^11.4.0-prerelease.18",
-    "@o3r/eslint-plugin": "^11.4.0-prerelease.18",
-    "@o3r/schematics": "^11.4.0-prerelease.18",
-    "@o3r/telemetry": "^11.4.0-prerelease.18",
-    "@o3r/test-helpers": "^11.4.0-prerelease.18",
+    "@o3r/build-helpers": "^11.4.0-prerelease.19",
+    "@o3r/eslint-plugin": "^11.4.0-prerelease.19",
+    "@o3r/schematics": "^11.4.0-prerelease.19",
+    "@o3r/telemetry": "^11.4.0-prerelease.19",
+    "@o3r/test-helpers": "^11.4.0-prerelease.19",
     "@openapitools/openapi-generator-cli": "~2.13.0",
     "@schematics/angular": "~18.2.0",
     "@stylistic/eslint-plugin-ts": "~2.4.0",

package/schematics/typescript/shell/templates/base/readme.md

@@ -127,10 +127,14 @@ You will need to compute this information with the two timezones -- the airport'
 The Otter framework has introduced the `utils.Date` and `utils.DateTime` objects to replace the `Date` implementation and convert the date returned by the API as if it were in the
 timezone of the user.
 
-Dates can be generated as `utils.Date` or `string` depending on the value of the `stringifyDate` option. This ensures that the timezone will not impact the date. 
-In the case of `date-time` objects, the default type used is the native `string` and `Date` type depending on the `stringifyDate` option value.
-
-If you want to generate a date-time using `utils.DateTime`, you can do it at property level thanks to the `x-local-timezone` vendor.
+#### Date format
+Dates can be generated as `utils.Date` or string depending on the value of the `stringifyDate` option.
+This ensures that the timezone will not impact the date as the native `Date` object does not handle the 'dd/mm' format well.
+
+#### Date-time format
+In the case of `date-time` objects, the default type used is the native string or the native `Date` type depending on the `stringifyDate` option value.
+If you want to generate a date-time using `utils.DateTime` (see the [previous section](#the-timezone-issue)), you can do it at property level thanks to
+the `x-local-timezone` vendor.
 
 If you need to keep the timezone information, extend the model and create a new field directly in the SDK.
 As this field does not exist in the specification, it will not be part of the base model but of the core model instead (the first one being completely generated from the API specifications).