Skip to main content

Qlik

cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
su_pyae
Creator
Creator
‎2022-01-20 05:05 PM

Inconsistent dateformat while loading from AWS

Hello everyone, 

I am seeing something weird. While loading data from AWS, I noticed that the tags for the two dates are not the same even though they are in the same format. 

  Example Tags
Col 1 12/18/2020 00:00:00 Numeric, Integer, Timestamp, Date
Col 2 12/24/2021 00:00:00 Numeric, Timestamp

I tried using Date(), Date#() and Timestamp#() to change Col 2 as Date but I couldn't. 

Then, suddenly, without having to do anything, Col2 suddenly have the same tags as Col 2 while using WHERE to filter some data. 

After reloading the same script, it suddenly becomes #numeric and #timestamp again. 

 

I am trying to understand how or why this happened. 

Thank you for your help in advance. 

 

Labels (3)
Labels
328 Views
0 Likes
1 Solution

Accepted Solutions
marcus_sommer
MVP
MVP
‎2022-01-21 03:14 AM

The recognized/applied format is only one part of the data-interpretation which leads then to the tags. More important as the format are the values itself.

Col1 is interpreted as a number without any decimals and therefore it's numeric + an integer and additionally it could be considered as date and a timestamp. Col2 instead has anywhere a decimal-recognition (maybe there is really a single-value with decimals or the formatting from the raw-data could not uniquely resolved) and therefore it's not an integer anymore and within it could be also no date.

Very important is further that this isn't related to the single loadings else to the whole datamodel because the field-values are distinctly stored within the system-tables and within the data-tables are just bit-stuffed pointer to the system-tables. This means each (temporary ?) load before or after these loadings could impact the interpretation.

Beside this within many scenarios is it beneficially not to keep timestamps else to split them into dates and times and if calculations to them are needed to add them again mit date + time - both fields connected with own master calendar/timetable to provide all needed kinds of period- and time-fields with all needed formatting and as pure numeric values.

- Marcus

View solution in original post

250 Views
1 Reply
marcus_sommer
MVP
MVP
‎2022-01-21 03:14 AM

The recognized/applied format is only one part of the data-interpretation which leads then to the tags. More important as the format are the values itself.

Col1 is interpreted as a number without any decimals and therefore it's numeric + an integer and additionally it could be considered as date and a timestamp. Col2 instead has anywhere a decimal-recognition (maybe there is really a single-value with decimals or the formatting from the raw-data could not uniquely resolved) and therefore it's not an integer anymore and within it could be also no date.

Very important is further that this isn't related to the single loadings else to the whole datamodel because the field-values are distinctly stored within the system-tables and within the data-tables are just bit-stuffed pointer to the system-tables. This means each (temporary ?) load before or after these loadings could impact the interpretation.

Beside this within many scenarios is it beneficially not to keep timestamps else to split them into dates and times and if calculations to them are needed to add them again mit date + time - both fields connected with own master calendar/timetable to provide all needed kinds of period- and time-fields with all needed formatting and as pure numeric values.

- Marcus

251 Views