Actions
Bug #81
open
mailbox.org date format incompatibilities
Start date:
11/06/2025
Due date:
11/14/2025 (10 days late)
% Done:
40%
Estimated time:
8:00 h
Description
mailbox.org send since 1-2 weeks an incompatible date format. At least in getlastmodified property.
See user request here: https://projects.shbe.net/boards/4/topics/110
Just confirmed that L2CPBG drops message:
[ERR] 20:24:43 [carddav] Failed loading [dav] AddressBook 'Globales Adressbuch':
loadAddressesByChunks('/carddav/6/', ...) failed with:
MultiGetAdrBooks('/carddav/6/', ...) failed with chunk 1/1 error:
property <DAV: getlastmodified>:
parsing time "Thu, 06 Nov 2025 19:13:15 UTC" as "Mon Jan _2 15:04:05 2006":
cannot parse ", 06 Nov 2025 19:13:15 UTC" as " "
Updated by Jörg Ebeling 18 days ago
- % Done changed from 0 to 20
- Estimated time changed from 6:00 h to 8:00 h
Updated by Jörg Ebeling 18 days ago
- % Done changed from 20 to 40
mailbox.org is sending (at least) a wrong getlastmodified date/time format.
Here's the response body of my test contact:
<?xml version="1.0" encoding="UTF-8"?>
<D:multistatus xmlns:D="DAV:" xmlns:CARD="urn:ietf:params:xml:ns:carddav" xmlns:MM="http://me.com/_namespace/">
<D:response>
<D:href>/carddav/6/5759d948-2c59-4402-b86e-154b6b9a0fbb.vcf</D:href>
<D:propstat>
<D:prop>
<D:getetag>2746089-2-1762456395763</D:getetag>
<D:getlastmodified xmlns:b="urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/" b:dt="dateTime.rfc1123">Thu, 06 Nov 2025 19:13:15 UTC</D:getlastmodified>
<address-data xmlns="urn:ietf:params:xml:ns:carddav"><![CDATA[BEGIN:VCARD
VERSION:3.0
EMAIL;TYPE=work:test66@mailbox.org
FN:Jörg Ebeling
PRODID:-//Open-Xchange//8.42.63//EN
REV:2025-11-06T19:13:15Z
N:Ebeling;Jörg
TEL;TYPE=cell:0XXX XXX 00 80
UID:5759d948-2c59-4402-b86e-154b6b9a0fbb
END:VCARD]]></address-data>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
Relevant reference: RFC 4918 Section 15.7 - getlastmodified Property which say:
...
Value: rfc1123-date (defined in Section 3.3.1 of [RFC2616])
...
whereas Section 3.3.1 of [RFC2616] writes:
HTTP applications have historically allowed three different formats
for the representation of date/time stamps:
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
The first format is preferred as an Internet standard and represents
a fixed-length subset of that defined by RFC 1123 [8] (an update to
RFC 822 [9]). The second format is in common use, but is based on the
obsolete RFC 850 [12] date format and lacks a four-digit year.
HTTP/1.1 clients and servers that parse the date value MUST accept
all three formats (for compatibility with HTTP/1.0), though they MUST
only generate the RFC 1123 format for representing HTTP-date values
in header fields. See section 19.3 for further information.
5.2.14 of RFC 1123 states:
The syntax for the date is hereby changed to:
date = 1*2DIGIT month 2*4DIGIT
All mail software SHOULD use 4-digit years in dates, to ease
the transition to the next century.
There is a strong trend towards the use of numeric timezone
indicators, and implementations SHOULD use numeric timezones
instead of timezone names. However, all implementations MUST
accept either notation. If timezone names are used, they MUST
be exactly as defined in RFC-822.
....
So we have to support reading of RFC 822 but that clearly states:
...
zone = "UT" / "GMT" ; Universal Time
; North American : UT
/ "EST" / "EDT" ; Eastern: - 5/ - 4
/ "CST" / "CDT" ; Central: - 6/ - 5
/ "MST" / "MDT" ; Mountain: - 7/ - 6
/ "PST" / "PDT" ; Pacific: - 8/ - 7
/ 1ALPHA ; Military: Z = UT;
; A:-1; (J not used)
; M:-12; N:+1; Y:+12
/ ( ("+" / "-") 4DIGIT ) ; Local differential
; hours+min. (HHMM)
...
But not "UTC"
Actions