• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Its about time

 
Pat Farrell
Rancher
Posts: 4678
7
Linux Mac OS X VI Editor
  • Likes 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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!
 
Palak Mathur
Ranch Hand
Posts: 342
IntelliJ IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Randall Twede
Ranch Hand
Posts: 4439
3
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Date i found difficult, but i found Calendar fairly easy to use. still i look forward to the improvement.
 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 64959
86
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Calendar is an abomination. Passing magic numbers? We might as well be writing C in 1972.
 
Randall Twede
Ranch Hand
Posts: 4439
3
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
in a way i wish i was writing C in 1972. or even assembly. at least my skills would be in demand.
 
Rob Spoor
Sheriff
Pie
Posts: 20546
56
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 64959
86
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Constants or not, they're magic numbers. Awful, awful, awful.
 
Palak Mathur
Ranch Hand
Posts: 342
IntelliJ IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Christopher Perrault
Greenhorn
Posts: 1
Java Linux Netbeans IDE
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

 
Paul Clapham
Sheriff
Posts: 21116
32
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Palak Mathur
Ranch Hand
Posts: 342
IntelliJ IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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!
 
Paul Clapham
Sheriff
Posts: 21116
32
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Palak Mathur
Ranch Hand
Posts: 342
IntelliJ IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Tim Holloway
Saloon Keeper
Pie
Posts: 18212
53
Android Eclipse IDE Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic