Hi!
When we were using mailsync to synchronize mailboxes via the imap
protocol we got the following error:

0000000a APPEND INBOX () " 8-Jul-2003 18:21:29 +0200" {1149}
0000000a BAD Invalid date-time in Append command
Error: IMAP protocol error: Invalid date-time in Append command
Error: Invalid date-time in Append command

We had to revert this patch from cyrus21-imapd_2.1.13-4.diff.gz:
--- cyrus21-imapd-2.1.13.orig/lib/mkgmtime.c
+++ cyrus21-imapd-2.1.13/lib/mkgmtime.c
@@ -134,10 +134,12 @@
        */
        t = (t < 0) ? 0 : ((time_t) 1 << bits);

+#if 0
        /* Some gmtime() implementations are broken and will return
         * NULL for time_ts larger than 40 bits even on 64-bit platforms
         * so we'll just cap it at 40 bits */
        if(bits > 40) bits = 40;
+#endif

        for ( ; ; ) {
                mytm = gmtime(&t);


after that we get the following:

0000000e APPEND INBOX (\Seen) " 8-Jul-2003 17:52:27 +0200" {1149}
+ go ahead

On i368 it worked fine - we only faced this problem on alpha (where time_t is 64
bits). Since the above patch doesn't work, it would be nice to know why you
made this patch so that we might be able to fix the real problem and not run
into problems later.

regards,

Tom

Sorry it took me some time to reply.

Fix gmtime() in glibc, please.  It is about time people fix it, it makes no
sense to cripple the app to work around such an obious bug... if time_t is
64bits, then gmtime must use all those 64 bits properly.

Oh, it DOES work. If I enable it, it will work around the issue...  I
disabled it on purpose because I hate such fixups.  If glibc is buggy, we
fix it and keep going, instead of just working around the problem :)

I was NOT aware glibc was broken at the time, though.  Were I, I would have
sent an email to the alpha porters list requesting their help to fix
glibc...

retitle 200641 glibc gmtime() broken for 64bit time_t (in arch=alpha)
reassign 200641 glibc
thanks

I hope the glibc guys fix this issue...

Could you explain what the bug is?  If you have spare time to make
sample program to reproduce this issue, please let us know.

Regards,
-- gotom

The problematic function is mkgmtime.  If it returns NULL, Cyrus refuses the
message on the grounds that something is fishy, and that generated the bug
reports on archs such as Alpha.

#244922: cyrus21-imapd: invalid date with pine imap access
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=244922&archive=yes

I have also attached a few emails from the cyrus-users ML that also give
some details on the problem.   Re-reading them, I see that the current
"workaround" of capping at 40 bits will let us work with years from -32873
to 36812, which is quite enough as far as I am concerned ;-)  But let's
get back to the gmtime() issue...

As I understand it, Cyrus expected (before we added the cap at 40 bits) that
if you give it a time_t that is 64-bits long, it can use all 64 bits
meaningfully and won't overflow tm->year.

How that plays with the following comment in gmtime(3), I don't know:
       The  gmtime()  function converts the calendar time timep to
       broken-down time representation, expressed in Coordinated Universal
       Time (UTC).  It may return NULL when the year does not fit into an
       integer.

What size is an integer on alpha? singed 64 bits?  If so, how could gmtime
be overflowing the year?

Dates that are reported to be problematic (see attached files):
9-Aug-2002 11:55:32 -0400
26-Mar-2003 11:12:21 +0100

(but I think any date will do, actually).

Now, reading it all to send you this email, I am not so sure glibc gmtime is
broken, since Cyrus *is* assuming that "time_t has 64 bits imples that an
int also does" in that code, which is dubious at best.

OTOH, if an int has 64 bits on alpha, glibc gmtime is to allow 64bits worth
of tm->year before it returns NULL...

So, if int on alpha is 32 bits, we have no bug and I apologise for not
doing the full homework before, and trusting the word from others that it
was a gmtime bug.

Hello all.

This message is about bug #412569, but informations
are also relevant to issue #200641.

I looked deeper into zdump and gmtime issues.

And I think there is no error in libc's gmtime or zdump.

$ zdump -v /usr/share/zoneinfo/UTC
/etc/localtime  -9223372036854775808 = NULL
/etc/localtime  -9223372036854689408 = NULL
/etc/localtime  9223372036854689407 = NULL
/etc/localtime  9223372036854775807 = NULL
$

In my opinion it is actually correct output.
Documentation of zdump needs to be updated
to fully reflect this strange (but correct) behaviour.

Why?