rpbouman
commented
9 months ago I think for now that we will rename the existing date and time derivations to "iso date" and "iso time", and adding new date and time derivations which return a duckdb DATE and TIME type respectively.
This is effectively choosing option 2. We can always decide to remove the derivations later.
The date and time derivations were a temporary crutch to allow friendly formatting of timestamp values. Now that we have formatting support also on the axes, we should reconsider, as the formatting should now be done by formatters.
As I see it now there are two possibilities :
1) the current implementation of these derivations was always wrong, as they merely format the timestamp value into a iso date and time respectively. The proper implementation should have delivered a duckdb DATE and TIME value respectively, and these can then be formatted into user friendly values
2) The current date and time representations were chose so precisely because they represent ISO date and time, which we think is a good and desirable thing as they are very portable and "universal". Derivations that deliver a DATE and TIME datatype are still useful because they can be formatted into local formats, but that does not change that we still would also like to be able to easily get a plain iso date or time, and since the current implementation does precisely that, it seems wasteful to first have duckdb create DATE and TIME values, and then letting the result javascript Date values be formatted down again to strings.