CritasWang commented on code in PR #15:
URL:
https://github.com/apache/iotdb-client-nodejs/pull/15#discussion_r3568348278
##########
src/utils/DataTypes.ts:
##########
@@ -99,6 +99,51 @@ export enum TSDataType {
// OBJECT = 12, // Reserved - not yet implemented
}
+/**
+ * Convert a JavaScript Date (or an already-encoded yyyyMMdd number) to the
+ * IoTDB DATE wire format: an INT32 encoded as year*10000 + month*100 + day
+ * (e.g. 2024-01-01 -> 20240101).
+ *
+ * This matches the Java client's DateUtils.parseDateExpressionToInt and the
+ * C# client. The calendar date is taken from the Date's UTC components,
+ * consistent with `new Date("2024-01-01")` which parses as UTC midnight.
+ *
+ * @param value - Date object or a yyyyMMdd integer (passed through unchanged)
+ * @returns The yyyyMMdd integer encoding
+ */
+export function parseDateToInt(value: Date | number): number {
+ if (value instanceof Date) {
+ return (
+ value.getUTCFullYear() * 10000 +
+ (value.getUTCMonth() + 1) * 100 +
+ value.getUTCDate()
+ );
+ }
+ return value;
Review Comment:
Fixed in 4aacd83. Updated all remaining days-since-epoch references to the
yyyyMMdd contract with examples (`20240101` for 2024-01-01): the type table and
both conversion tables in `docs/data-types.md`, and the data-type tables in
`docs/user-guide-tree.md` and `docs/user-guide-tree-zh.md`. Verified with `grep
-rn "days since\|epoch" docs/ README*` that no numeric-DATE-as-day-count
wording remains; the existing code examples only pass `Date` objects, so none
needed changes.
##########
src/utils/DataTypes.ts:
##########
@@ -99,6 +99,51 @@ export enum TSDataType {
// OBJECT = 12, // Reserved - not yet implemented
}
+/**
+ * Convert a JavaScript Date (or an already-encoded yyyyMMdd number) to the
+ * IoTDB DATE wire format: an INT32 encoded as year*10000 + month*100 + day
+ * (e.g. 2024-01-01 -> 20240101).
+ *
+ * This matches the Java client's DateUtils.parseDateExpressionToInt and the
+ * C# client. The calendar date is taken from the Date's UTC components,
+ * consistent with `new Date("2024-01-01")` which parses as UTC midnight.
+ *
+ * @param value - Date object or a yyyyMMdd integer (passed through unchanged)
+ * @returns The yyyyMMdd integer encoding
+ */
+export function parseDateToInt(value: Date | number): number {
+ if (value instanceof Date) {
+ return (
+ value.getUTCFullYear() * 10000 +
+ (value.getUTCMonth() + 1) * 100 +
+ value.getUTCDate()
+ );
+ }
+ return value;
+}
+
+/**
+ * Convert an IoTDB DATE wire value (INT32, year*10000 + month*100 + day)
+ * back to a JavaScript Date at UTC midnight of that calendar date.
+ *
+ * Inverse of {@link parseDateToInt}; matches the Java client's
+ * DateUtils.parseIntToDate.
+ *
+ * @param value - The yyyyMMdd integer (e.g. 20240101)
+ * @returns Date at UTC midnight of the encoded calendar date
+ */
+export function parseIntToDate(value: number): Date {
+ const year = Math.trunc(value / 10000);
+ const month = Math.trunc(value / 100) % 100;
+ const day = value % 100;
+ const date = new Date(Date.UTC(year, month - 1, day));
+ // Date.UTC maps years 0-99 to 1900-1999; correct that explicitly
+ if (year >= 0 && year < 100) {
+ date.setUTCFullYear(year);
+ }
+ return date;
+}
Review Comment:
Fixed in 4aacd83. Both helpers now validate like the Java client:
`parseDateToInt` rejects invalid `Date` objects (NaN time),
non-finite/non-integer numbers, and numbers whose yyyyMMdd decomposition is not
a real calendar date (month 1-12, day range incl. leap years, year 1000-9999
matching `DateUtils`); `parseIntToDate` applies the same validation before
constructing, so e.g. `20230229` now throws a descriptive `Error` instead of
silently normalizing to 2023-03-01. null/undefined handling is unchanged
(callers filter nulls before these helpers). Added boundary unit tests:
20240229 (leap day) ok, 20230229 / 20241301 / 20240100 / year 999 / year 10000
/ `new Date(NaN)` / non-integer / legacy days-epoch 19723 all throw.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
