Handling time in Cesium Native and the native runtimes
We've gotten surprisingly far in Cesium Native without support time-dynamic data, but I wanted to start thinking about it with time-dynamic 3D Tiles on the mid-term roadmap.
Supporting time in Cesium Native would allow us to support:
- Vector formats like CZML, KML, GPX
- Raster formats like WMTS + Time
- Time-dynamic 3D Tiles
- glTF animations
At a high level this might look like:
- A
CesiumTimelibrary with core classes likeClockandJulianDateported from CesiumJS - A mechanism for converting game engine / system time to Cesium time
- Passing time to
Cesium3DTilesSelection::Tileset::updateView - Game engine-specific widgets like clock and timeline
@kring I'm curious to hear your thoughts. I'm sure it's been in the back of your mind since the start of Cesium Native and Cesium for Unreal.
Is the Julian calendar a requirement of time-dynamic 3D Tiles? I would propose relying on std::chrono for the clock and date operations, but these are tied to the proleptic Georgian calendar. Though there are libraries that build on chrono for Julian date support.
The plan is to use ISO 8601 strings for time-dynamic 3D Tiles (same as CZML) and convert them to JulianDate internally. JulianDate is pretty convenient since it's just the number of days (possibly fractional) since the epoch. Easy and fast to do time comparisons / calculations.
std::chrono::time_point<std::chrono::system_clock, std::chrono::days> would achieve the same thing, wouldn't it? And it provides easy conversions to a std::chrono::year_month_day.
@azrogers good point, maybe we can use std::chrono instead of rolling our own.
I was initially going to say "but leap seconds!" Until I realized std::chrono even has some kind of support for leap seconds these days (C++20). Needs some investigation, but looks promising.
I believe using system_clock would outsource leap second handling to the OS anyways. utc_clock claims to handle leap seconds itself, but I don't know how well (or, to be honest, how) it does this.