You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a query result contains a string that "looks" like a "yyyy-mm-dd" date it is converted into an epoch millisecond. This could be any string field, regardless of its intended purpose.
If a column contains a mixture of values formatted in this way and values that are NOT formatted in this way, the values in this format are converted to epoch milliseconds and the values that are not in this format are not converted.
In this case choosing to format the column as a date to kind of "undo" the transformation is not sufficient.
Redash should not do this kind of arbitrary transformation on string data values unless it is explicitly requested by the user.
A similar issue was reported in #5237 but never fixed, as the user was able to work around it because that column was actually supposed to be a date.
However, I discovered this issue in a scenario where the field in question was mostly not intended to be a date, and having a large number stuck in there for some fields and not others was very confusing, to say the least.
The text was updated successfully, but these errors were encountered:
When a query result contains a string that "looks" like a "yyyy-mm-dd" date it is converted into an epoch millisecond. This could be any string field, regardless of its intended purpose.
If a column contains a mixture of values formatted in this way and values that are NOT formatted in this way, the values in this format are converted to epoch milliseconds and the values that are not in this format are not converted.
In this case choosing to format the column as a date to kind of "undo" the transformation is not sufficient.
Redash should not do this kind of arbitrary transformation on string data values unless it is explicitly requested by the user.
A similar issue was reported in #5237 but never fixed, as the user was able to work around it because that column was actually supposed to be a date.
However, I discovered this issue in a scenario where the field in question was mostly not intended to be a date, and having a large number stuck in there for some fields and not others was very confusing, to say the least.
The text was updated successfully, but these errors were encountered: