This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
The API documentation for SimpleDateFormat says exactly what parsing will accept as a time-zone when the "Z" character is used in the format string. I don't see where it says it will accept a "Z" as a time-zone. And it doesn't mention accepting colons either. So I would say the class is working according to its published specifications.
Their sample is in the offset format, sans the colon. "Z" as a suffix for Zulu time is certainly part of RFC822. I guess Sun's implementation is non-standard, in that it doesn't appear to comply with RFC822. I wonder what standard they were coding against, or what feeds can use their format? The data I'm reading complies with the published RFC822 format, so it's a bummer I apparently can't use SimpleDateFormat to parse it.
If your gripe is that the documentation says "RFC822 time zone" but doesn't provide a full implementation of RFC822, then you're absolutely correct. But I would expect you aren't the first person to run into this... have you googled for third-party classes which might work better?
Joined: Nov 06, 2000
Their lack of support for the colon is non-standard too. I did Google for other parsers, but didn't find any within the time span of my patience. Apache Commons has one, but it only formats -- it doesn't parse. Oh well.
Joined: Nov 06, 2000
Paul Clapham wrote:If your gripe is that the documentation says "RFC822 time zone" but doesn't provide a full implementation of RFC822, then you're absolutely correct. But I would expect you aren't the first person to run into this... have you googled for third-party classes which might work better?
By the way, I'm not trying to gripe -- I'm just confused by the behavior and thought I might have made a mistake in my parse pattern, or misunderstood the documentation. I'm still not sure if their documentation is wrong, or their implementation. Is there some place on the Sun site where I can document this apparent inconsistency?
The time / date / calendar APIs in Java are unfortunately not great on some points, and that's why Joda Time is a very popular open-source library to deal with time and date values better.
There's an initiative, JSR-310, for a new standard time / date / calendar API for Java, which is based on Joda Time - so something like Joda Time will probably become standard in a future version of Java.