From mboxrd@z Thu Jan 1 00:00:00 1970 Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=91.121.71.147; helo=nautica.notk.org; envelope-from=asmadeus@notk.org; receiver= Received: from nautica.notk.org (nautica.notk.org [91.121.71.147]) by hurricane.the-brannons.com (Postfix) with ESMTPS id CE0A1788C0 for ; Wed, 6 Jun 2018 16:52:26 -0700 (PDT) Received: by nautica.notk.org (Postfix, from userid 1001) id 24C92C009; Thu, 7 Jun 2018 01:52:22 +0200 (CEST) Date: Thu, 7 Jun 2018 01:52:07 +0200 From: Dominique Martinet To: edbrowse-dev@edbrowse.org Subject: Re: [edbrowse-dev] batch move and batch delete Message-ID: <20180606235207.GA6583@nautica> References: <20180506130719.eklhad@comcast.net> X-BeenThere: edbrowse-dev@edbrowse.org List-Id: Edbrowse Development List MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20180506130719.eklhad@comcast.net> User-Agent: Mutt/1.5.21 (2010-09-15) (resent to the list, sorry for double-mail to Karl) Karl Dahlke wrote on Wed, Jun 06, 2018: > You know what's interesting? > When my friend Erwin sends me an email, and I look at it through imap, or pop3 for that matter, > there is sender and subject and size, but no date and time. > Run at db3 and you can see why. > > parseHeaderDate fails on mer., 06 juin 2018 14:52:10 +0200 > > Oops! That's something I never thought of. > Our routine expects English day and month, not French. > So almost all the emails in Erwin's imap will show no date/time. > I could change the routine to recognize English or French, but is there a more general approach? > Not that I can think of. > Just brute force programming. > Identify the language first, which isn't trivial, then use the days and months in that language. > I'll see if there's a way to do this that isn't totally painful. Hm, you might be looking at it the wrong way, I think edbrowse is the only mail client that will localize the Date: field. RFC4021 (Registration of Mail and MIME Header Fields) through RFC822 (ARPA INTERNET TEXT MESSAGES) (and RFC2822 (Internet Message Format), which is probably different but says the same) both specify a strict format for date that leaves no room for translation ; so this really should be simpler to parse. That being said, for this particular mail my client (mutt) gave up on parsing Date: and fell back to printing the date when the mail was received by the server, in the most recent (first) Received: field. That is formatted by your mail server and will always be respectin the format described in the RFC that we can parse. There actually is another timestamp in the mail metadata (in mbox format, the first line "From x Wed May 2 00:19:29 2018" ; in maildir format the mtime of the file itself ; it's been a while since I've last done imap but you can request "INTERNALDATE" in FETCH commands that is the same) ; I've always thought mutt used it, but now I just checked it's really based on first Received: field... Not sure why, but why not? Back to edbrowse, I'm not sure what we should do - it probably won't hurt to implement a fallback if we fail to parse Date, but we should also make sure we format the Date properly when we send it so that would fix your apparent bug for the forseeable future anyway. Leaving it up to you :) -- Dominique | Asmadeus