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

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

View File

@ -120,7 +120,9 @@
* *
* GLib is attempting to unify around the use of 64bit integers to * GLib is attempting to unify around the use of 64bit integers to
* represent microsecond-precision time. As such, this type will be * 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.
*/ */
/** /**

View File

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