mailing list archives

meli community discussions

⚠️ if something does not work as intended when interracting with the mailing lists,
reach out Github mirror Gitea repo @epilys:matrix.org

[Imap-protocol] Future INTERNALDATE

E-mail headers
From: Timo Sirainen <tss@iki.fi>
To: imap-protocol@u.washington.edu
Date: Fri, 08 Jun 2018 12:34:42 -0000
Message-ID: 1238715476.12172.239.camel@timo-desktop permalink / raw / eml / mbox 
Any thoughts on if it's a bad idea for server to convert future
INTERNALDATE timestamps in APPEND parameter to current time?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: This is a digitally signed message part
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20090402/39562cb7/attachment.sig>
Reply
E-mail headers
From: markrcrispin@panda.com
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:42 -0000
Message-ID: alpine.OSX.2.00.0904021641300.40001@hsinghsing.panda.com permalink / raw / eml / mbox 
On Thu, 2 Apr 2009, Timo Sirainen wrote:
> Any thoughts on if it's a bad idea for server to convert future
> INTERNALDATE timestamps in APPEND parameter to current time?

In my opinion, this is a case of GIGO (Garbage In, Garbage Out).  Barring 
the invention of time machines, either the client or the server has the 
wrong time.

The server is free to do as it pleases in such a case.  I think that your 
idea of coercing to current time is a fine idea that would probably give 
the best user experience.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
Reply
E-mail headers
From: arnt@gulbrandsen.priv.no
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:42 -0000
Message-ID: GERoZH4TIPZi9wipsg0Ecw.md5@lochnagar.oryx.com permalink / raw / eml / mbox 
Timo Sirainen writes:
> Any thoughts on if it's a bad idea for server to convert future
> INTERNALDATE timestamps in APPEND parameter to current time?

A fine idea say I. Although I'd allow perhaps a minute or three into the 
future, since PC clocks are so bad and tools like imapsync use append.

NTP _should_ take care of clock skew, but I've seen (even rather 
expensive) rackmount servers that failed (x)ntpd's sanity checks.

Arnt
Reply
E-mail headers
From: lyndon@orthanc.ca
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:42 -0000
Message-ID: alpine.OSX.2.00.0904021655460.5929@peregrin.wbb.net.cable.rogers.com permalink / raw / eml / mbox 
> The server is free to do as it pleases in such a case.  I think that your 
> idea of coercing to current time is a fine idea that would probably give the 
> best user experience.

I disagree. Given a 64-bit time_t it's not inconceivable that time travel 
will be invented before we overflow epoch+(2^63-1).

Unless your server can accurately read my mind (something that will NOT 
happen before the above-mentioned milestone occurs), just leave this stuff 
alone. Otherwise I might give you a quit-dorking-around-with-my-data 
experience.)

--lyndon
Reply
E-mail headers
From: barryleiba@computer.org
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:42 -0000
Message-ID: 6c9fcc2a0904040746i7830f6fdy10c0d2bf95deb244@mail.gmail.com permalink / raw / eml / mbox 
Perhaps the user/client intends to post this message as one that stays
at the top of a date-sorted list until after a future event takes
place.  We do that sort of thing all the time.

That said, I'd probably rather use RFC822.date for that, than INTERNALDATE.

Barry
Reply