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
There is a variety of classes to handle date, time etc.
I would like to unify the time stamp representation to include date and time in utc to a common epoch.
My motivation is to avoid the hassle of handling any rollover. Currently modules that do calculate a time period need a logic to handle time stamps of potentially different dates. For the gui output there should be unit like routines that handle the local or utc representation in a same manner we handle altimeter values.
Chrono is a good base for all that, even I would like to hide the ugly details of chrono and aggregate it instead of a derived class design.
The cost would be additional memory per time stamp, or with a variation on precision depending on time since epoch, when thinking of a double representation.
The current implementation is nicely encapsulated, so pushing this forward should not be difficult, whereas it will have impact and needs to be tested intensively.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
There is a variety of classes to handle date, time etc.
I would like to unify the time stamp representation to include date and time in utc to a common epoch.
My motivation is to avoid the hassle of handling any rollover. Currently modules that do calculate a time period need a logic to handle time stamps of potentially different dates. For the gui output there should be unit like routines that handle the local or utc representation in a same manner we handle altimeter values.
Chrono is a good base for all that, even I would like to hide the ugly details of chrono and aggregate it instead of a derived class design.
The cost would be additional memory per time stamp, or with a variation on precision depending on time since epoch, when thinking of a double representation.
The current implementation is nicely encapsulated, so pushing this forward should not be difficult, whereas it will have impact and needs to be tested intensively.
Beta Was this translation helpful? Give feedback.
All reactions