-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
Low
-
None
-
Affects Version/s: 5.12.29, 10.3.13, 11.2.0, 11.3.0
-
Component/s: Assets - Object, Type and Schema
-
Severity 3 - Minor
Issue Summary
When conducting an assets import, integers representing a datetime in Unix Epoch time format with nanosecond precision are incorrectly parsed using the WindowsNT datetime parser, resulting in the incorrect datetime on the assets object.
Steps to Reproduce
- Create a new empty assets object schema and assets object type, which includes a new attribute of type 'DateTime'

- Construct a csv with the following content
name,integer_datetime_representation
"Test Object",638292024000000000

(representing a date in year 1990 when parsed using Unix Epoch datetime format, with nanosecond precision)

(Representing a date in year 3623 when parsed using WindowsNT datetime format)
- Create a new csv import configuration for the new assets object schema, uploading the above csv file (all other configuration can remain unchanged).

- Create an object type mapping to the new csv import (all configuration in the create modal can remain default), set data locators and matching assets attributes after creation.

- Run a sync.


- Review the newly imported assets object.
Actual Results
In JSM 11.2.0 or less, Imported assets object shows an incorrect date in 2023 (see bug: https://jira.atlassian.com/browse/JSDSERVER-16449)

(note the above server is configured with UTC timezone)
In JSM 11.3.0, Imported asset object shows an incorrect date in 3623

(note the above server is configured with timezone offset of GMT +09:00)
Expected Results
Integer is correctly parsed using Unix Epoch format to a date on 25 March 1990

(note the above server is configured with timezone offset of GMT +09:00)
Workaround
In 11.3.0, modify integers representing Unix Epoch Datetimes to have second, millisecond or microsecond precision (i.e. remove the trailing three digits from 638292024000000000 (nanosecond precision) -> 638292024000000 (microsecond precision)) to avoid incorrectly parsing as a WindowsNT datetime.
In 11.2.0 or less there is no known workaround for this behavior. A workaround will be added here when available
Versions Tested
Please confirm all versions that have been tested for this issue, and indicate whether the tested version is affected or not affected, below:
| Testing Requirements | Version | Affected Version |
|---|---|---|
| Customers Reported Version | ||
| Most Recent Bug-Fix Release | ||
| Previous Major Release | ||
| Most Recent LTS | 11.3.0 | Yes |
| Previous Supported LTS | 10.3.13 | Yes |
| Previous Supported LTS | 5.12.29 | Yes |
| Other Versions.. | 11.2.0 | Yes |
| (Add rows as needed) |
- is related to
-
JSDSERVER-16448 Assets Import, integers representing a datetime in Unix Epoch time format do not parse
-
- Gathering Impact
-
-
JSDSERVER-16449 When conducting an assets import, integers representing a datetime parsed using Windows NT time format do not retain the two most significant digits of the year
-
- Gathering Impact
-
- relates to
-
JSDSERVER-16315 Epoch format date values imported from a database into asset object attributes are incorrect
-
- Closed
-
- links to
- mentioned in
-
Page Loading...