This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
jose chiramal wrote:I tried using something like this, but in vain :
And the reason is that dates are NOT Strings.
It's a common beginner's mistake: I'll make everything a String because I understand what it is.
The problem is that Java can't. To it, a String is just a String; it has no idea that you just put a date in it, so it will sort it according to the rules for Strings, not dates.
I would recommend using SimpleDateFormat, and using parse() to convert these Strings to Dates. They're easy to sort after that.
Those three-letter time zones may give you trouble though - they can be ambiguous if you're getting them from around the world. I see CET from Europe and PST from North America - if you only use those, you're probably OK, but if you have many more, there may be ambiguity about what they mean. In fact there's already ambiguity because on 08/02/2012, no one should be using Pacific Standard Time. They might be using Philippine Standard Time, but that seems unlikely. This probably indicates a misconfigured system somewhere.
Mike Simmons wrote:In fact there's already ambiguity because on 08/02/2012, no one should be using Pacific Standard Time. This probably indicates a misconfigured system somewhere.
Unless 08/02/2012 means (as it does in practically every major country in the world except the US) the 8th of February.
Don't you just love nationhood?
Joined: Mar 05, 2008
Good point - but Jose did provide a format string for the SimpleDateFormat which provides an important clue as to which is intended. Of course, if whoever has provided the CET time was formatting it with a different convention, that gives a much more serious area of ambiguity.
Warning: a Java Date object does not have a timezone. Only Java's date format classes have a timezone and locale. Dates are simply the number of milliseconds since midnight on a specific date. There is no explicit or even implicit timezone information.
Second warning: Date is a four letter word in Java. Perhaps some day we will see all of the Date class and its method be deprecated and replaced by something sensible.
Pat Farrell wrote:Only Java's date format classes have a timezone and locale.
Actually, that's not true. Calendar (and more specifically GregorianCalendar) has a timezone too.
Date is a four letter word in Java. Perhaps some day we will see all of the Date class and its method be deprecated and replaced by something sensible.
Again, there's nothing particularly wrong with the Date class per se; it's all the stuff around it that needs overhauling. IMO the Calendar class and its children are way too complicated.
And until whatever JSR-310 morphs into comes up for review again, there's always Joda Time.
Joined: Feb 12, 2010
Thanks for your posts.
Could someone please provide me a sample code where I would be able to sort the below data(ascending / descending). The sorting should happen based on the TimeZone where the program is running.The first question is if its possible to sort the time belonging to different TimeZones(eg GMT,PDT etc...all time zones used worlwide). I would like to sort based on the date and the start time(example for 08/02/2012 12:30 PM - 06:45 PM CET ; I would like to sort based on the date and the start time ie based on 08/02/2012 and 12:30pm CET) :
Winston Gutkowski wrote:Actually, that's not true. Calendar (and more specifically GregorianCalendar) has a timezone too.
They accept a timezone, which is used to set the internal value. Its when you print/format it, you specify the meaningful timezone/locale.
Joined: Mar 05, 2008
Actually, it looks like you've really got a range between two different times there. That complicates things a bit - you need to decide how you would want to sort those. Should you order them by the start time? End time? Some combination of the two? If I were you, I would probably just use the start time, ignore the end time, create a new String containing just the start time and time zone, and parse that string using SimpleDateFormat. But I don't know if that works for you.
jose chiramal wrote:Could someone please provide me a sample code where I would be able to sort the below data(ascending / descending).
Actually, you have several things going on here:
First, Mike's absolutely right (and I completely missed it)
08/02/2012 12:30 PM - 06:45 PM CET Is a date RANGE, not a date.
Joda Time (as I suggested above) has a class called Interval, which you can use to store precisely such things, but you still have to convert the above String into two separate date strings (or, as he suggested, just ignore the second time).
Your original code contained:
SimpleDateFormat sdf = new SimpleDateFormat("MM/dd/yyyy, HH:mm:ss a z"); which seems a perfectly reasonable format for a single date; so why don't you just convert your input string to two strings of that format and then run parse()? - and don't forget the ','.
Any help with sample code would be much appreciated.
Much better that you digest the advice you've been given and try something yourself. If you run into problems, come back.
The sorting should happen based on the TimeZone where the program is running.
Actually, you're almost certainly wrong there. Your dates have different timezones, so there are two possibilities:
1. You want them grouped by timezone, and then sorted by date/time within each timezone group.
2. (Much more likely) You want them sorted according to which date/time is later.
If you convert your Strings to java.util.Date as you've been advised, and then sort the Dates, #2 will happen automatically, so I wouldn't obsess about 'the TimeZone where the program is running'.
For compatibility with JDK 1.1.x, some other three-letter time zone IDs (such as "PST", "CTT", "AST") are also supported. However, their use is deprecated because the same abbreviation is often used for multiple time zones (for example, "CST" could be U.S. "Central Standard Time" and "China Standard Time"), and the Java platform can then only recognize one of them.
So if you have three-letter time zones which aren't in the (undocumented) list, you're going to have to map those to Java TimeZone objects on your own. Note that the deprecation took place with Java 2.0, which was released in 1998, so this is not a new feature.
Joined: Feb 12, 2010
Is there any alternative that I could use then since Date is deprecated ?
Also mapping those timezones which aren't in the (undocumented) list may not be feasible since we don't know the list of timezones that would be used.
Joined: Mar 05, 2008
It might be worthwhile to spend some time investigating where exactly these lines of text come from. I mean, what system or systems generated them, where were they located, and did the people responsible for them actually know what they were doing? I suspect the answer to the last is no, they didn't. Because again, whoever is responsible for a summertime date labeled PST is someone who doesn't know how daylight saving time works in the Pacific time zone - if they knew what they were talking about, it would be labeled PDT. I am similarly suspicious of "CET" which should probably be CEST, but I know less about how the Euro time zones work, so I may be mistaken. Anyway, I would not trust the source of this data, and times may actually be off by an hour due to daylight saving.
While researching the answer to this question, you may also get an idea of what time zones they meant to use.
The Date class is not deprecated. Many specific constructors and methods are deprecated, yes. But the other constructors and methods are not deprecated, and it's perfectly acceptable to use the Date class as long as you do not use the deprecated methods.