BlackBerry date parsing and an hour's difference -

due limitation of date parsing on blackberry i'm trying roll own parse/deparse methods, seem falling foul of hour's difference somewhere, somehow.

i this:

long nowlong = system.currenttimemillis(); string nowstring = dateparser.longtostring(nowlong); date nowdatefromstring = dateparser.stringtodate(nowstring); date nowdatefromlong = dateparser.longtodate(nowlong); 

when outputted in order produces in console:

[139.46] 1369132556831 [139.46] 21 may 2013 11:35:56 europe/dublin [139.46] tue may 21 12:35:56 europe/dublin 2013 [139.46] tue may 21 11:35:56 europe/dublin 2013 

my simulator's time set 11:35 third statement - dateparser.stringtodate() - seems failing somewhere.

here implementation:

public static date stringtodate(string date) {     long l = httpdateparser.parse(date);     date d = new date(l);      return d; } 

as nowstring includes time zone i'd expect httpdateparser.parse() take in account seems not be.

how can correct this?

httpdateparser.parse() documented handle "gmt" or "tzd" assume "time zone designator". suspect expected (horrible, ambiguous) abbreviation format - example, might worth trying parse

21 may 2013 11:35:56 bst 

and seeing out. @ least take further in terms of diagnosing behaviour of httpdateparser. keeping time zone's tzdb id better idea in view, may need write own parsing code. still need handle local time ambiguity though, particular local time occurs twice due dst transitions.

it's not entirely clear input or expected output in case - how control have on format. i'd try use iso-8601 far possible, time zone identifer if need one. (if you're trying represent instant in time, i'd use iso-8601 representation of utc instant, complete z suffix indicate utc.)