'Date'-header is saved as localized value about android-sms HOT 8 CLOSED

Gmail shows two different dates: At thread level (message listing) it shows the 
last update time of the thread 
(which is upload time). When clicking on the thread, Gmail shows the individual 
message dates.

Is Gmail able to extract the date even if it's localized? I.e., is the 
individual message date correct in your 
example?

the X-smssync-id-header is localized correctly, so the overview's date is 
shown. the
individual date is not shown by gmail or any mailclient i use (kmail and mutt).

here's a more or less complete header as example:

[...]
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: base64
Date: Mi, 25 Mrz 2009 11:19:37 +0100
References: <lfj5y7lg1r9o7mmd012dt0ex.***@smssync.studer.tv>
X-smssync-id: 42
X-smssync-address: ***
X-smssync-type: 1
X-smssync-date: 1237976377000
X-smssync-thread: 14
X-smssync-read: 1
X-smssync-status: -1
X-smssync-protocol: 0
X-smssync-service_center: ***
X-smssync-backup_time: 29 Mar 2009 20:31:45 GMT
[...]

uh, i mean gmail shows the time the thread was updated correctly, the
smssync-backup_time header has nothing to do with this.

just the individual time isn't right, at least for months where the localized 
and
standard values differ, with april's messages for example gmail (and other 
mua's)
show the correct date because the german and english short form for april (apr) 
are
the same. at least at monday and saturday, where the short forms for the day 
are the
same.

I see, that makes sense. I'll investigate whether I can persuade the mail 
library to 
write times in us-en independent of the Java runtime locale.

Issue 36 has been merged into this issue.

Sorry for duplicate.

Maybe adding this piece of code after calling setSentDate in CursorToMessage 
class
will override the mail library bug ?
DateFormat df =  new SimpleDateFormat("EEE, dd MMM yyyy HH:mm:ss 
Z",Locale.ENGLISH);
msg.setHeader("Date", df.format(then));

Haven't tested (still no SDK installed).

The newest version of the IMAP library I'm using has this bug fixed. 
Unfortunately it introduced other bugs that 
prevented me from releasing an update. I hope to be able to look into it real 
soon(tm).

I have submitted a new version of the IMAP library in revision r57 and this bug 
should be fixed in the next 
release.