luc14n0/glib
1
0
Fork 0
mirror of https://gitlab.gnome.org/GNOME/glib.git synced 2024-12-26 15:36:14 +01:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'wip/gtimeval-document-year-2038-problem' into 'master'

Browse Source 
Document that GTimeVal is subject to the year 2038 problem on 32-bit systems

See merge request GNOME/glib!302
This commit is contained in:
Philip Withnall 2018-09-05 10:55:43 +00:00
commit d2f412590e
2 changed files with 9 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
glib/gdate.c
View File

@ -120,7 +120,9 @@
*
* GLib is attempting to unify around the use of 64bit integers to
* represent microsecond-precision time. As such, this type will be
* removed from a future version of GLib.
* removed from a future version of GLib. A consequence of using `glong` for
* `tv_sec` is that on 32-bit systems `GTimeVal` is subject to the year 2038
* problem.
*/
/**

10
glib/gtimer.c
View File

@ -538,10 +538,12 @@ g_time_val_from_iso8601 (const gchar *iso_date,
* variation of ISO 8601 format is required.
*
* If @time_ represents a date which is too large to fit into a `struct tm`,
* %NULL will be returned. This is platform dependent, but it is safe to assume
* years up to 3000 are supported. The return value of g_time_val_to_iso8601()
* has been nullable since GLib 2.54; before then, GLib would crash under the
* same conditions.
* %NULL will be returned. This is platform dependent. Note also that since
* `GTimeVal` stores the number of seconds as a `glong`, on 32-bit systems it
* is subject to the year 2038 problem.
*
* The return value of g_time_val_to_iso8601() has been nullable since GLib
* 2.54; before then, GLib would crash under the same conditions.
*
* Returns: (nullable): a newly allocated string containing an ISO 8601 date,
* or %NULL if @time_ was too large