Time type

[simonbyrne]

If we Float32, we can easily go past the point at which the type can no longer accurately keep track of time, e.g. https://buildkite.com/clima/climaatmos-longruns/builds/1171#018a7855-5fa2-42e2-b8b2-1989c0b397ca/143-366

[ Info: Saving diagnostics to HDF5 file on day 1510 second 0
[ Info: Saving diagnostics to HDF5 file on day 1520 second 0
[ Info: Saving diagnostics to HDF5 file on day 1530 second 0
[ Info: Saving diagnostics to HDF5 file on day 1540 second 0
[ Info: Saving diagnostics to HDF5 file on day 1550 second 0
[ Info: Saving diagnostics to HDF5 file on day 1560 second 256
[ Info: Saving diagnostics to HDF5 file on day 1570 second 224

The problem is that

julia> maxintfloat(Float32) / (60*60*24)
194.18074f0

i.e. after 194 days, we can no longer represent exact seconds.

Some options:

1. Always use Float64 for time
2. Use integer multiples of some small unit (e.g. milliseconds)
3. Use Julia DateTime objects (which internally are stored in milliseconds): the advantage of this is that it would make a log of the day/month/year logic we use elsewhere easier.

All 3 would probably some changes to ClimaTimeSteppers

[szy21]

We have this issue here too: CliMA/ClimaTimeSteppers.jl#76

[Sbozzolo]

I found another occurrence of this issue: the diagnostic module computes how often to compute a given diagnostic by taking the ratio of period / dt and checking that this is is an integer. With Float32, this ends up failing often when period is >3-4 orders of magnitude larger than dt (because the ratio doesn't return an integer even if it should).

[Sbozzolo]

Note also that

julia> 100. / 0.1f0
999.999985098839

julia> 100.f0 / 0.1f0
1000.0f0

[charleskawczynski]

Let's try to get Dates working with ClimaTimeSteppers