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 t
David Bremner writes:
>
> 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.
There is another cast that is harder to avoid:
notmuch_message_get_
