Refactor mrptime to not break on year 2038 and not have problems with DST
During review of !28 (closed) I came up with the following plan to tackle MrpTime and co instead:
-
Remove all usages of mrp_time2_*
from other files thanmrp-time.c
. One case (planner-calendar-dialog.c) could use mrp_time_(de)compose or GDateTime directly, another (planner-scale-utils.c) could use mrp_time_* instead or GDateTime directly -
This leaves us just modification on "seconds since epoch" mrptime
(time_t
), which then can be done directly instead of usingmrp_time2_*
API, using a temporary GDateTime if that helps to offload the handling to glib (most of it will). This also micro-optimizes the actual usages we have, as instead of doing things likeset_epoch(1970, 1, 1); add_seconds(epoch)
that the old bridging did, we can just do it directly fromepoch
(this is just an example) -
mrp_time2_* API can now be deleted instead of making it work with GDateTime too -
Changing mrptime to be gint64
instead oflong
-g_date_time_new_from_unix_utc ()
and co actually work with gint64, not time_t, thus does not have year 2038 problem (it has year 9999 problem instead😄 ). This requires changing some usages, including g_param_spec in some places where mrptime is used as a property.
After all this, I think we should be more or less good until we decide whether to work with "seconds since epoch", move over to directly using GDateTime everywhere, or something else.
Edited by Mart Raudsepp