Which email header field is used for Date column in webmail

[mzaleski]

All of the emails I'm getting from PCMagazine/Extremetech websites are having the same issue. In the webmail folder view, all of the Dates are listed as "Unknown Date". If I open the message, the Date: field is filled with a date of the form "Fri, 15 Feb 2008 17:08:19 UT".

Is the issue that it ends with "UT" rather than "UTC"? According to the information I dug up (http://tycho.usno.navy.mil/systime.html), UTC is based on an atomic clock and UT is based on astronomical observations.

Or is the problem that the folder view uses a field other than "Date:"?

[StevenUnderwood]

All of the emails I'm getting from PCMagazine/Extremetech websites are having the same issue. In the webmail folder view, all of the Dates are listed as "Unknown Date". If I open the message, the Date: field is filled with a date of the form "Fri, 15 Feb 2008 17:08:19 UT".

Is the issue that it ends with "UT" rather than "UTC"? According to the information I dug up (http://tycho.usno.navy.mil/systime.html), UTC is based on an atomic clock and UT is based on astronomical observations.

Or is the problem that the folder view uses a field other than "Date:"?

I believe the date should be in the form: Date: Mon, 25 Feb 2008 15:09:32 -0500 rather than using any characters to define the offset.

[mzaleski]

I believe the date should be in the form: Date: Mon, 25 Feb 2008 15:09:32 -0500 rather than using any characters to define the offset.

Hrmm, ok, I pulled up RFC 2822 email spec. You are correct in that the current spec calls for +/- and 4 digit offset for timezone. Section 4.3 "Obsolete Date and Time" indicates a large number of textual timezones including "UT", "GMT", "EST" and so on (defined in RFC 822).

[mzaleski]

Hrmm, ok, I pulled up RFC 2822 email spec. You are correct in that the current spec calls for +/- and 4 digit offset for timezone. Section 4.3 "Obsolete Date and Time" indicates a large number of textual timezones including "UT", "GMT", "EST" and so on (defined in RFC 822).

Digging deeper, I searched IMP bugs and found: http://bugs.horde.org/ticket/5717 . That bug report was closed as "won't fix". After asking on IMP's mailing list, the problem is in PHP 5.x (worked fine in PHP4.x). See http://thread.gmane.org/gmane.comp.horde.imp/23623: interestingly, someone quoted the RFC 2822 spec and it states that email clients must still be able to process the old timezone entries from RFC 822.

Searching for PHP bugs, I found http://bugs.php.net/bug.php?id=42486, in which the PHP developers refused to fix it. This is frustrating.

It sounds like the PHP devs are telling their users that they have to do a search/replace of "UT" with "UTC" before calling strtotime().

Everyone is claiming it isn't a bug, but the net result is IMP is not a RFC 2822 compliant email package due to this problem. And yes, I realize that both PHP and IMP are open source packages with volunteers doing the coding.

[Farelf]

Digging deeper ...

Thanks for the research, appreciated. Maybe airing the shortcomings will assist towards a re-evaluation of the PHP stand on compliance concerning this field.

[Tommy]

Thanks for the research, appreciated. Maybe airing the shortcomings will assist towards a re-evaluation of the PHP stand on compliance concerning this field.

Of course another option would be to complain to the SENDER that their server doesn't meet the current email standard!

Have you tried displaying your mail according to arrival time? (Click Options, click Mailbox and Folder Display Options.) That might make the display more consistent since the arrival date stamp won't depend on some other server's outdated mail software.