Its about time

Wow, finally. Someone has noticed that Java's data and time classes and APIs are a royal pain to use. They are neither clean, consistent, nor orthogonal.

Bring on a new set!

Pat Farrell wrote:Wow, finally. Someone has noticed that Java's data and time classes and APIs are a royal pain to use. They are neither clean, consistent, nor orthogonal.

Bring on a new set!

Check the project site:

http://sourceforge.net/apps/mediawiki/threeten/index.php?title=ThreeTen

Date i found difficult, but i found Calendar fairly easy to use. still i look forward to the improvement.

Calendar is an abomination. Passing magic numbers? We might as well be writing C in 1972.

in a way i wish i was writing C in 1972. or even assembly. at least my skills would be in demand.

Magic numbers in Calendar? Isn't every allowed option provided as a constant?
I have no problems with Calendar, except the fact that Calendar.JANUARY == 0 (not 1) while Calendar.SUNDAY == 1. If they could do it for one, why not for the more logical other?

Constants or not, they're magic numbers. Awful, awful, awful.

I just hope that with ThreeTen, the Calendar manipulations become easier. Currently, the API is so complex that you need to do research only on the API to know which one will do what you want it to do.

I found the whole date/calendar concept to be a complete PITA to learn when I first stumbled upon it. It's been a while since I did anything with it, but as I can remember, the good thing was you could do almost anything you wanted with it. The class has just about anything you can ask for once you spend the time to learn it. I would agree that the upfront work seems a bit much.

Bear Bibeault wrote:Constants or not, they're magic numbers. Awful, awful, awful.

Just the fact that there's a Calendar.JANUARY constant is a design failure. So even if you replaced those constants by some kind of enum, it still wouldn't help.

Calendar is an abstraction which is supposed to support any calendar (or at least any calendar which repeats yearly and breaks the 365-ish days into a smallish group of months). So besides the Gregorian calendar it should also be able to represent the Hebrew calendar, the Islamic calendar, the Persian calendar, and so on -- and in none of those is the first month called "January". So that constant violates the rule that a class shouldn't know anything about its subclasses.

Paul Clapham wrote:

Bear Bibeault wrote:Constants or not, they're magic numbers. Awful, awful, awful.

Just the fact that there's a Calendar.JANUARY constant is a design failure. So even if you replaced those constants by some kind of enum, it still wouldn't help.

Calendar is an abstraction which is supposed to support any calendar (or at least any calendar which repeats yearly and breaks the 365-ish days into a smallish group of months). So besides the Gregorian calendar it should also be able to represent the Hebrew calendar, the Islamic calendar, the Persian calendar, and so on -- and in none of those is the first month called "January". So that constant violates the rule that a class shouldn't know anything about its subclasses.

I think there was a discussion regarding this on ThreeTen Issue tracker on GitHub. Nice point I must say!

Palak Mathur wrote:I think there was a discussion regarding this on ThreeTen Issue tracker on GitHub. Nice point I must say!

Yes, I wouldn't be surprised. I've found that if I have what I think is a good idea, then a lot of other people will already have had that good idea. And many of them will have expressed it better than I did, and a lot of them will already have done something based on it. That's just how it is with the web these days.

Paul Clapham wrote:

Palak Mathur wrote:I think there was a discussion regarding this on ThreeTen Issue tracker on GitHub. Nice point I must say!

Yes, I wouldn't be surprised. I've found that if I have what I think is a good idea, then a lot of other people will already have had that good idea. And many of them will have expressed it better than I did, and a lot of them will already have done something based on it. That's just how it is with the web these days.

I think the way you explained the issue was much better than the way we discussed it on the issue tracker.

Paul Clapham wrote:

Bear Bibeault wrote:Constants or not, they're magic numbers. Awful, awful, awful.

Just the fact that there's a Calendar.JANUARY constant is a design failure. So even if you replaced those constants by some kind of enum, it still wouldn't help.

Calendar is an abstraction which is supposed to support any calendar (or at least any calendar which repeats yearly and breaks the 365-ish days into a smallish group of months). So besides the Gregorian calendar it should also be able to represent the Hebrew calendar, the Islamic calendar, the Persian calendar, and so on -- and in none of those is the first month called "January". So that constant violates the rule that a class shouldn't know anything about its subclasses.

I'm glad you said "365-ish", since the various lunar calendars are not 365.25 days long (approximately).

Calendary.JANUARY isn't a "magic number". It's a Manifest Constant. "1" is a magic number. As can be seen by the fact that the first month of the Gregorian Calendar class is 1, but the Calendar.SUNDAY is 0. A well-implemented Hijri (Islamic Year) subclass of Calendar should include a Hijri.RAMADAN manifest constant. The days of the week are worse, since they're basically the same as the day number, and the day starts officially at sunset, not at midnight. Which means that a truly well-functioning Hijri Calendar class needs to know the latitude and longitude it's working from (and technically speaking, the weather, as well).

The justification, I think, for putting Gregorian Manifests in the base Calendar class is simply that it's the common denominator that sooner or later everyone else has to deal with, so it makes translation easier. However, since the Manifest Constants aren't enums, they're not type-safe.