Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
-
None
-
None
Description
Now the default precision of timestamp used by exportCsv is "ms", which has no problem because the default precision used in AbstractClient is also "ms" and this is good.
However, there exists a difference as to the realization. In exportCsv.writeTime function the default format is realized by:
case "default": dateTime = ZonedDateTime.ofInstant(Instant.ofEpochMilli(rs.getLong(1)), zoneId); bw.write(dateTime.format(DateTimeFormatter.ISO_OFFSET_DATE_TIME) + ","); break;
And in AbstractClient the default format is realized by:
long integerofDate = timestamp / 1000; String digits = Long.toString(timestamp % 1000); ZonedDateTime dateTime = ZonedDateTime .ofInstant(Instant.ofEpochSecond(integerofDate), zoneid); String datetime = dateTime.format(formatter); int length = digits.length(); if (length != 3) { for (int i = 0; i < 3 - length; i++) { digits = "0" + digits; } } return datetime.substring(0, 19) + "." + digits + datetime.substring(19);
Take t=10 for example, the first realization results in
1970-01-01T08:00:00.01+08:00
and the second realization results in
1970-01-01T08:00:00.010+08:00
The difference will bring inconvenience when trying to reuse some code tools in IoTDB to analyze the exported csv. For example, DatetimeUtils.convertDatetimeStrToLong for parsing timestamp in sql does not accept the first format.
So I guess a better way is to use a unified realization (the second type)?
Attachments
Issue Links
- is a child of
-
IOTDB-842 Better Export/Import-CSV Tool
- Closed
- links to