tl;dr: GTimeVal
and g_get_current_time()
are not year-2038-safe and have been deprecated; use GDateTime
and g_get_real_time()
instead.
One of the latest changes in GLib (released in 2.61.2) is the deprecation of GTimeVal
, g_get_current_time()
, and a number of other time functions. This is because we can’t guarantee they’re wide enough on all platforms to be year-2038-safe.
Instead, you should use GDateTime
or, if you just need to store epoch time, guint64
. They are year-2038-safe — and with that, GLib should be entirely year-2038-safe.
GTimeVal
is used in a number of places, and widespread (but simple) changes will need to be made to stop using it. You will likely have already seen some deprecation warnings popping up to inform you of this, if you use any C-based and GLib-based libraries.
If you can’t allocate time to fixing these deprecation warnings yet, you can silence them by explicitly stating your minimum and maximum supported versions of GLib. If your minimum supported version of GLib is older than 2.62, you won’t see deprecation warnings for GTimeVal
(since it was deprecated in 2.62, and your code is claiming to need to support older GLib versions than that).
You can do that by setting the following in meson.build
:
common_c_args = [
'-DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_44',
'-DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_60',
]
and then using common_c_args
in the c_args
field of every executable and library you define in Meson. Your minimum required GLib version should match the version you list in your dependency('glib-2.0')
.
So,
GTimeVal tv;
g_get_current_time (&tv);
g_message ("Current time: %lu", tv.tv_sec);
becomes
gint64 tv;
tv = g_get_real_time ();
g_message ("Current time: %" G_GINT64_FORMAT, tv / G_USEC_PER_SEC);
And
GTimeVal tv;
if (!g_time_val_from_iso8601 ("2019-08-24T10:47:05Z", &tv))
g_error ("Conversion failed");
becomes
g_autoptr(GDateTime) dt = g_date_time_new_from_iso8601 ("2019-08-24T10:47:05Z", NULL);
if (dt == NULL)
{
g_error ("Conversion failed");
return;
}
gint64 time_val = g_date_time_to_unix (dt);
/* or (simpler) use the #GDateTime directly */
Finally
GTimeVal tv = some timeval;
g_autofree gchar *tv_in_iso8601 = g_time_val_to_iso8601 (&tv);
g_message ("In ISO 8601 format: %s", tv_in_iso8601);
becomes the following, using the new g_date_time_format_iso8601()
function:
g_autoptr(GDateTime) dt = some GDateTime;
g_autofree gchar *dt_in_iso8601 = g_date_time_format_iso8601 (dt);
g_message ("In ISO 8601 format: %s", dt_in_iso8601);
This is a weird decision, as if GLib is the only library affected by this. Pushing forward like this rather than waiting for a proper solution just creates problems, and does not help anyone.
Also guint64 really should have a gtime64 typedef or something.
Have you got a better suggestion?
Quite aside from the year-2038 problem, `GTimeVal` was a pretty poor API for tracking dates/times, since it didn’t support storing the associated timezone for display. `GDateTime` is easier to use in most cases anyway.
Hi, for g_file_info_get_modification_time, do we have a replacement?
Thanks.
Yes, [`g_file_info_get_modification_date_time()`](https://developer.gnome.org/gio/unstable/GFileInfo.html#g-file-info-get-modification-date-time). All the replacement APIs are linked to from the old APIs’ documentation.
Oh, in unstable... that's why I didn't find it. Thanks.
So now every program that uses gtk gets a bunch of depreciation warnings by default, then. Any idea when gtk is going to stop using these functions internally?