'date' function - results seem wrong

[mueschel]

I tried to use the 'date' function, but can't make any sense of the outputs:

date("2020-01-01") -> "2020.064453125" = 2020 + 1/16
date("2020-00-02") -> "2020.00390625" = 2020 + 1/256
date("2020-12-31") -> "2020.810546875" = 2020 + 415/512
date("2020-11-10") -> "2020.70703125" = 2020 + 181/256

What does the function actually calculate?

[mmd-osm]

The calculated value is not documented and is only useful in comparison expressions, rather than interpreted as such.

Calculation happens here: https://github.com/drolbr/Overpass-API/blob/master/src/overpass_api/statements/string_endomorphisms.cc#L145

[mueschel]

This implementation seems to be a reasonable choice regarding performance (because it avoids actual division and fiddling with leap years).

I think it would be quite nice to have an actual conversion function, e.g. to Unix timestamps. This would enable us to e.g. calculate the age of an object.

[mmd-osm]

When checking for >1 year, 2, 3 or 4 years, this probably doesn't really matter, simply use date(), it's a heuristic approach anyway. Also, I don't see what you would do with a unix timestamp when using MapCSS. How would this make your query easier?

(for context see https://forum.openstreetmap.org/viewtopic.php?pid=812877#p812877)

[mueschel]

Periods of full years are fine, but everything else gets really fuzzy. E.g. 1.5 years is anywhere between 15 and 21 months.
A Unix timestamp (or years with decimals) is just a standard representation of times and simple to do calculations with.

MapCSS has an 'eval' function that enables us to do basic calculations with this timestamp and e.g. calculate a smooth color scale on the fly. Unfortunately this doesn't work yet in Overpass Turbo due to its limited support of 'eval'.

In my case another advantage would be to remove load from the server and put it to the client. I.e. the server would do only a simple conversion for each object, but doesn't have to make all the comparisons.