[Users] FYI: Bad date formats and sorting...

[Pierre Fortin]

On Wed, 1 Jun 2016 07:42:49 +0200 Andrej Kacian wrote:

>On Tue, 31 May 2016 19:26:24 -0400
>Pierre Fortin <pf at pfortin.com> wrote:
>
>> Yup...  looked into the code and thought the best place to "fix" this
>> was as the message(s) arrived...  I'm willing to give it a shot if
>> someone can point me to the right bit of code (inc.c?) where the
>> message arrives and just before it gets written, I can give it a
>> try...    
>
>We generally have a policy of not modifying contents of received
>messages, so instead of fixing the date, I think it would be better to
>just parse the obsolete date string correctly. Look in procheader.c,
>function procheader_scan_date_string().

Ah-ha! (burst of enlightenment :)

So just the parsing is needed...  

================ leaving for the benefit of other readers ===========
The RFCs also talk about obsolete date formats. In particular, the US
timezones and even list a translation:
  UT, GMT = +0000
  EDT -0400
  EST -0500
  CDT -0500
  CST -0600
  MDT -0600
  MST -0700
  PDT -0700
  PST -0800
and also mentions military TZ references (though I've never seen these):
  a,A = -1 through i,I = -9
  j,J not used (appears to be northern Pacific)
  k,K = -10 through y,Y +12
  z,Z +0000
================ leaving for the benefit of other readers ===========

Paul Holland sent me a private note with CEST (Central European
Summer Time) which doesn't appear to be RFC referenced...

Notwithstanding the above, Paul H. provided this code:

  // Date: Tue May 31 03:10:08 CEST 2016
  result = sscanf(str, "%3s %3s %d %d:%d:%d %s %d",
                 weekday, month, day, hh, mm, ss, zone, year);
  if (result == 8) return 0;

which handles the case I originally posted about:
  // Date: Wed May 25 22:23:29 EDT 2016 

Cool!  More digging revealed that, except for this date format, CM already
handles pretty much all of the above at remote_tzoffset_sec() in
src/common/utils.c

Continually amazed by this great MUA   :)

>Regards,