What do you have so far, and where are you stuck? Can you write the code that prompts the user for input, and get that input into your program?
Originally posted by john doah:
actually it is in preparation for a test, and he said there would be something like that on the test, so i am trying to figure out how to do it...
In that case, you should definitely get some working code together. What do you have so far?
Originally posted by john doah:
...i will probably have to use a loop, having every 4th year add and extra day because of leap years...
That would be one approach.
Using java.util.Date would be an alternative. But if you've never used this before, it can be a bit intimidating to dive into (especially if you're preparing for a test and haven't worked with this in class). So I'm not sure how complex of a solution you're looking for. What level class is this?
Originally posted by marc weber:
Hmmm... I might be wrong here, but if you haven't worked with Date or Calendar classes before, then I guess I would recommend working on your loop approach -- so you know you have something workable that you can demonstrate on a test.
I'd say this would be an ideal time to dive in and do some research to expand your knowledge...
You learn by doing that, not by slavishly copying things that are spoonfed to you by others (whether teachers or helpful forum members).
[ December 12, 2006: Message edited by: MaryT Tsele ]
1.) The java.util.Date class in Java is not a date in the sense that the word is commonly used (i.e. 12th of December 2006). It is simply the number of milliseconds between Jan 1, 1970 and now.
2.) The java.text.DateFormat class will format and parse from a string to a java.util.Date and vice versa.
3.) The java.util.Calendar class and its derivations (usually java.util.GregorianCalendar if you are in a western country) are the things that know about a calendar. A calendar maps an instant in time (like the number of milliseconds since 1/1/1970) to some standard enumeration system and are a surprisingly complex subject. Java does attempt to deal with that complexity (which is why Java date manipulation can be complicated). You probably don't need calendars for what you are doing.
You now can figure out how to turn a String into a Date.
You know (or can figure out) how many milliseconds are in a day.
That should be enough.
Welcome to JavaRanch! Thanks for you post, but in the beginners forum, we try to encourage posters to work out their own solutions. Pointing them in the right direction is great, but giving them the complete code is usually not helpful (especially when they haven't posted any of their own code).
You should avoid storing dates in String objects and use a Date or Calendar instead.
Parsing a date from a String involves a certain amount of guesswork and can be error prone even with a helper class like DateFormat.
If you ever need the date as a String, you can always generate a String in the proper format.
i.e. one of these kinds of dates:
DateFormat parse() method.
This just seems to make the math easier when doing any kind of date calculation.
In particular, don't store in local time or using a Calendar.
BTW: The following code is a illustration of the difficulties in interpreting calendar string values. The output follows the code, but the code is self contained so its easy to verify the result. This will work in US timezones only, 'cause it is specific to the shift from DST to ST.
The date '1162102200000L' is within the "extra hour" on DST/ST boundary (i.e. between 1AM and 2AM on the last Sunday in October). The delta '3600000L' is exactly 1 hour in milliseconds.
Doing date math on Strings would require taking stuff like this into account.