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.
If you're doing timezone-sensitive operation in a country like Australia that have many different timezone with pretty complex daylight saving changes in between, and if your product will run on a UNIX/LINUX platform, then maintaining the timezone definition becomes quite important.
If I am not mistaken, Java doesn't use the olson database installed on local machine (i.e the "TZ" env variable), but rather maintain its own timezone database in the JRE distribution. It also make sense for Java to do this to make it cross-platform.
So somewhere in your product document, you'll also need to add section about updating the JRE installation with future updates, to ensure that the timezone definition is accurate & relevant.
But if you don't ever have to deal with daylight savings, then probably you don't have to worry about this too much.
Actually, for most things these days, with recent Java versions, you should think in terms of Calendar, not Date. Convert to a Calendar, then you can print it in zillions of formats, time zones, languages, etc.
[Pat Farrell]: Actually, for most things these days, with recent Java versions, you should think in terms of Calendar, not Date. Convert to a Calendar, then you can print it in zillions of formats, time zones, languages, etc.
Or you could just gouge your eyes out with sticks, if you're into that sort of thing.
Seriously, why would you want a Calendar for printing in different formats and time zones? Calendar doesn't do formats - you need to use a DateFormat (often SimpleDateFormat) for that. Which will then take a Date, not a Calendar, as the parameter for its format() method. Therefore Dates are easier to format. Calendar does have a time zone and locale, true - but so does DateFormat. Since you need a DateFormat anyway for formatting, you might as well use it to set the time zoneand/or locale too. Then you can ditch the god-awful, evil Calendar class entirely. Except, well, for the times when you actually need it. Which does happen, sure. Use it when you really need it. But for representing fixed date/times, Date is much less confusing, in my opinion -- despite the many deprecated methods, which are very clearly identified and should b avoided, and the amoral setter methods, which are not actually deprecated but which are totally unnecessary. Date should have been immutable, and anyone calling a setTime() method on a Date should be shot.
Originally posted by Pravin Johnson: I tried a lot.. But not able to convert this string "Mon Aug 18 10:00:00 IST 2008" to date.
Why not? Are you using the correct format specifier for the SimpleDateFormat object that you use to parse this string? Look at the API documentation of class SimpleDateFormat and find out what format specifier you need to use.
What did you try and what went wrong? [ August 26, 2008: Message edited by: Jesper Young ]
Originally posted by Mike Simmons: But for representing fixed date/times, Date is much less confusing, in my opinion -- despite the many deprecated methods, which are very clearly identified and should be avoided, and the amoral setter methods, which are not actually deprecated but which are totally unnecessary. Date should have been immutable, and anyone calling a setTime() method on a Date should be shot.
Other than the tons of deprecated methods, amoral setters and general lack of functionality, Dates are great.
And, I can never remember what member function that I want to use is still available when I use Date. When I use Calendar, its easy. I'm too lazy to remember complicated stuff. Two lines with a Calendar and I'm done.
I will wish that in Java 1.10 they rename and refactor all this stuff, its clearly a kludge on top of a hack.
Joined: Mar 05, 2008
Mmmm, when using Calendar, I can never remember which fields start at 0 and which start at 1. Or which of the many myriad class constants are intended for use as the type of a field, rather than the value of a field. In contrast, I have never had any trouble remembering how to use a Date. It's always seemed obvious: avoid anything that is dependent on timezone or locale. That's the job of a DateFormat. Also, you never explained how to format a Calendar for a specific date format, without converting to a Date at some point.
Originally posted by Pravin Johnson: DateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"); ... But not able to convert this string "Mon Aug 18 10:00:00 IST 2008" to date.
Are you possibly using that DateFormat object for parsing the date string you posted? That won't work, since the format is different. You need to use two different DateFormat objects, one for parsing the date, and one for outputting it as whatever format you need. [ August 27, 2008: Message edited by: Ulf Dittmer ]
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com