This is a partial fix for problems with 64 bit timestamps on 32 bit
architectures. In certain (not completely understood by me) cases this
casting causes 32bit overflows and yields negative timestamps for
times in the far future.

In g_mime_utils_header_decode_date_unix, there is really no reason to
cast to and from time_t.

In _notmuch_message_set_header_values, we rely on implicit casting of
the argument to Xapian::sortable_serialise to double.

 This is not a complete fix, but at least the timestamp ends up
 aparently correct in the database. It looks like there are still
 wonky conversions on reading the large timestamp from the database.

 lib/     | 2 +-
 util/gmime-extra.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/ b/lib/
index 0fa0eb3a..948626bd 100644
--- a/lib/
+++ b/lib/
@@ -1217,7 +1217,7 @@ _notmuch_message_set_header_values (notmuch_message_t 
                                    const char *from,
                                    const char *subject)
-    time_t time_value;
+    gint64 time_value;
     /* GMime really doesn't want to see a NULL date, so protect its
      * sensibilities. */
diff --git a/util/gmime-extra.c b/util/gmime-extra.c
index 04d8ed3d..af7b6d52 100644
--- a/util/gmime-extra.c
+++ b/util/gmime-extra.c
@@ -192,7 +192,7 @@ gint64
 g_mime_utils_header_decode_date_unix (const char *date)
     GDateTime *parsed_date = g_mime_utils_header_decode_date (date);
-    time_t ret;
+    gint64 ret;
     if (parsed_date) {
        ret = g_date_time_to_unix (parsed_date);

notmuch mailing list

Reply via email to