[glib/cherry-pick-14609b0b] g_file_info_get_modification_date_time: Calculate in integer domain

[Simon McVittie <smcv src gnome org>]

commit 5625760f127050fef783a17d59a7de51e1065cd8
Author: Simon McVittie <smcv collabora com>
Date:   Tue Oct 1 22:27:53 2019 +0000

    g_file_info_get_modification_date_time: Calculate in integer domain
    
    g_date_time_add_seconds() and g_date_time_add_full() use floating-point
    seconds, which can result in the value varying slightly from what's
    actually on disk. This causes intermittent test failures in
    gio/tests/g-file-info.c on Debian i386, where we set a file's mtime
    to be 50µs later, then read it back and sometimes find that it is only
    49µs later than the previous value.
    
    I've only seen this happen on i386, which means it might be to do with
    different floating-point rounding when a value is stored in the 80-bit
    legacy floating point registers rather than in double precision.
    
    g_date_time_add() takes a GTimeSpan, which is in microseconds;
    conveniently, that's exactly what we get from the GFileInfo.
    
    Bug-Debian: https://bugs.debian.org/941547
    Signed-off-by: Simon McVittie <smcv collabora com>
    
    
    (cherry picked from commit 14609b0b256b9c13162719868d4dfc2b419d885f)

 gio/gfileinfo.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
---
diff --git a/gio/gfileinfo.c b/gio/gfileinfo.c
index ab4cbea96..032d21144 100644
--- a/gio/gfileinfo.c
+++ b/gio/gfileinfo.c
@@ -1822,7 +1822,7 @@ g_file_info_get_modification_date_time (GFileInfo *info)
   if (value_usec == NULL)
     return g_steal_pointer (&dt);
 
-  dt2 = g_date_time_add_seconds (dt, _g_file_attribute_value_get_uint32 (value_usec) / (gdouble) 
G_USEC_PER_SEC);
+  dt2 = g_date_time_add (dt, _g_file_attribute_value_get_uint32 (value_usec));
   g_date_time_unref (dt);
 
   return g_steal_pointer (&dt2);