JSR 310 - Date and Time API voted in

Discussions

News: JSR 310 - Date and Time API voted in

Bookmark and Share Get thread feed

  1. JSR 310 - Date and Time API voted in (51 messages)

    JSR 310 - Date and Time API, has now passed its first hurdle. There were 15 yes votes and 1 non-vote. As co-spec lead of the JSR, and project lead of Joda-Time, I am now seeking to gather as many views, opinions, feedback and ideas as possible from anyone who has ever found Date or Calendar to be a real pain. The simplest way to contribute is to add your ideas and comments to this thread. All comments will be read!!! If you wish to help out on the JSR itself, the main development will be on mailing lists open to anyone to subscribe at the Java.net project. A wiki is also being used to gather ideas and focus discussion. So the question is: what pains you about the Date and Calendar APIs, and what ideas have you got for the new JSR API?
    Reply to this

    Threaded Messages (51)

  2. Re: JSR 310 - Date and Time API voted in[ Go to top ]

    I think the unfortunate thing about this is the timing. This should have been addressed about 8 years ago. In the interim I, and most of my collegues, have written countless utilities that have addressed our specifc issues with dates and time. Even so, I hope this goes forward. Stephen, I don't envy your task. I forsee volumes of opinions that all are slightly different from each other. John Murray SobeTech
    Reply to this Reply to original

  3. Changes to SimpleDateFormat[ Go to top ]

    I'd like to see an enhancement to SimpleDateFormat: Best guess parsing. This would allow users to generally enter whatever they wanted for a date and/or time, and give the system to have a good chance of figuring out what they intended. The method would take a string, and optionally a Locale, and use heuristics to figure out how to parse it. It should be able to identify separators if present, understand the separators that are likely to identify a time versus a date, and rule out what numbers represent based on allowable ranges being violated and standard conventions (like a year is likely to be either the first digits or the last). This is of course not foolproof, as a string of "01/02/03" could mean any month|day|year order. But in that case, using the locale (either provided or default for the VM) could provide a likely order. By displaying a normalized form of the date back to the user, they could verify whether the guess was correct. Note that this type of algorithm has been around for years. For example, getdate.y is used in many projects and even allows constructs like "next thursday" and "tomorrow" to be parsed correctly.
    Reply to this Reply to original

  4. Re: Changes to SimpleDateFormat[ Go to top ]

    For SimpleDateFormat I wish an option get compose a XML Schema dateTime compatible string. The "Z" Option only gives timezone as +0100, there is no possibility to get a +01:00. I have seen a bug report for this, but it isn't in yet. Next thing I wish is a more consistent use of date classes between different APIs. 1. JDBC: java.sql.Date,java.sql.Timestamp, java.sql.Time even is there may be a need for different setters (setTimestamp,setTime,setDate for the driver to figure out database type) but why couldn't all sql setter take a java.util.Date and all getters return java.util.Date (or its new replacement) 2. XML (DOM/SAX implementations Deprecate XMLGregorianCalendar and find a solution to put it under the new umbrella. Maybe the list is getting longer, but these are my problems with date handling
    Reply to this Reply to original

  5. Re: JSR 310 - Date and Time API voted in[ Go to top ]

    My first thought on reading the headline of this article was why don't they just deprecate Date and Calendar and add Joda DateTime and its related classes? I developed a Calendar application and was going nuts with the standard Java classes and when I discovered Joda it just simplified everything. Joda has a much more intuitive, logical design and support for Intervals, Durations, working out the difference between moments in time, Timezones etc. So I am very happy that the person in charge of this is a Joda person and would welcome Joda in its current state into the JDK. Of course you now have the advantage of hindsight so you can improve on Joda but from the extended exposure I have had with it already, I don't think it really needs much changed.
    Reply to this Reply to original

  6. intelligent date and time parsing[ Go to top ]

    Please include intelligent date and time parsing: o date "1" -> the first of the current month in the current year o time "10" -> 10:00 o ...
    Reply to this Reply to original

  7. Re: intelligent date and time parsing[ Go to top ]

    I'll add to this: please include ISO 8601 DateTime processing too! ________ MessAdmin, J2EE monitoring made easy!
    Reply to this Reply to original

  8. dateranges[ Go to top ]

    I really like .net's DateRanges. You can do things like: int milliseconds = (endDate-startDate).totalMilliseconds(); or you can ask for it in days, weeks, years..etc..
    Reply to this Reply to original

  9. Re: dateranges[ Go to top ]

    I really like .net's DateRanges. You can do things like:

    int milliseconds = (endDate-startDate).totalMilliseconds();

    or you can ask for it in days, weeks, years..etc..
    This is exactly the thing I need too. It has been mentioned a couple of times already, but just for my +1: We really need an interval / range type. Many other systems have that (including .NET , databases like Postgresql and even Joda time of course). For that range, I would like to have a range (pun not intended ;) ) of formatting options. E.g. I would like to format a range as "years : months : days", or as "minutes : seconds", or as "days : minutes : seconds", etc etc.
    Reply to this Reply to original

  10. Method to return Daylight transition date[ Go to top ]

    It would be great if the system provides a methods to return start date (Second Sunday of March) and end date (First Sunday of November) for a given year.
    Reply to this Reply to original

  11. Re: Method to return Daylight transition date[ Go to top ]

    Knowing the "as at" date of the DST information would be useful too, seeing as the DST rules change year to year (so the older the JVM, the more out of date the DST rules are likely to be). Cheers, Peter
    Reply to this Reply to original

  12. Re: JSR 310 - Date and Time API voted in[ Go to top ]

    JSR 310 - Date and Time API, has now passed its first hurdle. There were 15 yes votes and 1 non-vote.

    As co-spec lead of the JSR, and project lead of Joda-Time, I am now seeking to gather as many views, opinions, feedback and ideas as possible from anyone who has ever found Date or Calendar to be a real pain.

    The simplest way to contribute is to add your ideas and comments to this thread. All comments will be read!!!

    If you wish to help out on the JSR itself, the main development will be on mailing lists open to anyone to subscribe at the Java.net project. A wiki is also being used to gather ideas and focus discussion.

    So the question is: what pains you about the Date and Calendar APIs, and what ideas have you got for the new JSR API?
    I'd be happy just to have immutable Date objects
    Reply to this Reply to original

  13. Re: JSR 310 - Date and Time API voted in[ Go to top ]

    I'd be happy just to have immutable Date objects
    +1
    Reply to this Reply to original

  14. Re: JSR 310 - Date and Time API voted in[ Go to top ]

    What a surprise, the non-voter was Borland. Have they just given up on the JCP entirely?
    Reply to this Reply to original

  15. Cleaner API for TimeZone and defining daylight savings[ Go to top ]

    Not especially important, but setting daylight savings on SimpleTimeZone, I think, should be easier. Dealing with negative values to indicate "Day of week on or before day of month" mode is not a best way in my opinion. Why not define separate class only for daylight savings time definition? As someone else mentioned, getting start and end date for DST is nice to have.
    Reply to this Reply to original

  16. XmlGregorianCalendar...[ Go to top ]

    Data and Calendar must be fixed! but so must XmlGregorianCalendar...why XmlGregorianCalendar is not a java.util.Calendar I will never know, i guess it won't matter as long as the new API includes all the additional features of XmlGregorianCalendar. The most important part of a new data/time API (IMHO) is that APIs like jaxb/JPA/SQL/etc start using the new APIs so they can finally interoperate. And while you good folks at JSR 310 are at it, send google an email, so they can get their GWT support ready. 4th date/time API is a charm!
    Reply to this Reply to original

  17. Context[ Go to top ]

    The most important part of a new data/time API (IMHO) is that APIs like jaxb/JPA/SQL/etc start using the new APIs so they can finally interoperate.
    That's right. In most projects I was involved, those are places where temporal data types are used: 1. Database columns. 2. Database APIs (JDBC, Entity Beans, etc.) 2. User interface components and API (JSTL, JSF, Swing, ...) 3. Formating and parsing API (printf, DateFormat, ...) 5. Temporal data operations: 5a. on database side (mostly in order by and where clauses) 5b. in Java code Please don't focus only on 5b and repeat mistake of many JSR-s: Make very well designed framework, but miss to address too many problems from real life usage of framework. For example, one of the most annoying problem in the current temporal classes is java.util.Date and java.sql.Date/Time/Timestamp duality. Do you plan to solve it or make it worse: java.util.Date, java.sql.Date/Time/Timestamp and JSR 310 types. If you don't want to make it worse, you need to deprecate java.util.Data, java.sql.Date/Time/Timestamp, related classes and all methods from Java SE and Java EE where those classes are in parameters or return values. Otherwise, a set of static methods that operates on existing types is a better solution for most applications. Nebojsa
    Reply to this Reply to original

  18. Re: Context[ Go to top ]

    Deprecating java.util.Date would be a tough task. My guess is that the new API will exist as an option but that it won't be back-fitted into JDBC, et. al. I'm not sure how this could be done without either creating a bigger API mess or simply deprecating entire java.* packages. It will be nice to have a better API when you can use it but I think we'll be living with the old Date, Time, Calendar friends forever. Would an option be to replace java.util.Date entirely? It is funny that it has methods that have been deprecated since about version two. Isn't the point of deprecating a method that sooner or later you'll actually physically remove it?
    Reply to this Reply to original

  19. Re: Context[ Go to top ]

    It will be nice to have a better API when you can use it but I think we'll be living with the old Date, Time, Calendar friends forever.
    Just answer the question: If you teach students in an programming course and use Java programming language, what class you will use for dates? Using JSR 310 in one lesson, java.util.Date in the other and mix of the two APIs later, is bad answer. But if the only possible answer is "java.util.Date", then JSR 310 will be a marginal API for specific kind of applications. I want to see fixed mistakes related to date and time in Java generally. Another standard date and time API that is not used even in the rest of JDK is not very important to me. Nebojsa
    Reply to this Reply to original

  20. Times change[ Go to top ]

    Your argument reminds me of java.util back in the day when I learnt Java. Do you still use Vectors and Hashmaps? There was a time when java.util.List and java.util.Map weren't used in the rest of the JDK.
    Reply to this Reply to original

  21. Re: Times change[ Go to top ]

    Your argument reminds me of java.util back in the day when I learnt Java.

    Do you still use Vectors and Hashmaps?

    There was a time when java.util.List and java.util.Map weren't used in the rest of the JDK.
    And still he does have a point. Consider that java.util.Date is not only a pain to use. It is an entirely and totally wrong abstraction for a date. It is an abstraction for a timestamp and not for a date. It is just like coming out of one of those refactoring books. As for java.util.Calendar: I think its abstraction is rather fine. The only thing I am really missing are timezone agnostic dates and times. There is very little support for expressing something like "10th of December, 12 o'Clock" and not caring about the date.
    Reply to this Reply to original

  22. Re: XmlGregorianCalendar...[ Go to top ]

    Dates need to have a concept of timezone. In other words, if I instantiate a date for 8pm in 'America/New York', then ask for the hour component, (either through a calendar or directly -- however you want to break up responsibility there) -- I want it to have the value of '20' (8pm). If I want the date object in my local timezone, I should have a method that returns a properly adjusted date object. Along the same lines, if I parse a string into a date, and said string has a timezone indicator in it, I want to be able to retrieve that timezone from the Date. Now obviously there's an issue with 'America/New York' versus '+05:00' ISO -- the former infers daylight savings rules, the latter just tells you the offset from GMT at that particular day. I couldn't tell you from an ISO offset when the beginning of daylight savings time -- it might differ in Chile versus the United States, even though both might have the same offset from GMT. So, obviously, there are two types of timezones -- ones with daylight savings time metadata, and those without.
    Reply to this Reply to original

  23. Date, Time and Timestamp separation[ Go to top ]

    I'd like to see better Date, Time and Timestamp separation, like in java.sql today.
    Reply to this Reply to original

  24. Output formating[ Go to top ]

    It's a sad disfeature of the current date formating system that there are no broad standardized ways to convert a date to a string. I need to format a date in a predictable way for every locale. In every locale there should be a way to format with 4 digits for the year and always two digits for the month and day of month where the order of these elements is what changes. It should be optional to include the appropriate separators for the locale. Exsamples: 05.23.2007 and 05232007 for the americans 23.05.2007 and 23052007 for a lot of europeans 2007.05.23 and 20070523 for the sweeds and possibly others and the separators used are probably different for many locales. The last format should be available in every locale as an international standard format. The point is of course to have one format specification that will always give such a format whatever the locale may happen to be at runtime. All users understand such a format so it can always be displayed and stored (where a Java date can't - when you need to store it in text format) and it can always be parsed back into a date.
    Reply to this Reply to original

  25. Umm, nope...[ Go to top ]

    It's a sad disfeature of the current date formating system that there are no broad standardized ways to convert a date to a string.
    Exsamples:
    05.23.2007 and 05232007 for the americans
    23.05.2007 and 23052007 for a lot of europeans
    2007.05.23 and 20070523 for the sweeds

    No no no. Let's not make things even more complicated than they are: not everyone has to (or should) use the same separators; using ordering-specific separators make conversion a breeze.
    What should happen is much simpler: make use of ISO-supported canonical serializations, such as: DD.MM.YYYY (23.[0]5.2007) for europeans; MM/DD/YYYY (05/23/2007) for USians, and YYYY-MM-DD (2007-05-23) for programmers (as it's nicely sortable). These are the most common use cases as far as I know.
    For any other (per)mutation, allow format-based rules; but for these 3 common + common sense cases allow convenience methods.
    Reply to this Reply to original

  26. Interval[ Go to top ]

    We need interval as well. As available in many relational database engines and supported in JDBC of course. We need it with all it's difficult options and make sure it's implemented correctly and simply.
    Reply to this Reply to original

  27. Just copy Joda-Time[ Go to top ]

    Joda-Time has intervals, periods, immutable date / times, mutable date / times, configurable on-the-fly timezones.. Just copy joda-time, you can't go wrong doing that. :)
    Reply to this Reply to original

  28. +1 Joda-Time[ Go to top ]

    Joda-Time has been refined and optimized already. No need to reinvent the wheel again.
    Reply to this Reply to original

  29. Re: +1 Joda-Time[ Go to top ]

    I use nothing but Joda for products I work on. The JDK date libraries are a pile; slow, non-scalable, incorrect in some edge cases, non-intuitive, mutable. Do the brave thing, deprecate the whole lot and drop the Joda APIs in with java. package names. Add new methods to the JDBC spec in the same version. In my world (which isn't everyone's of course) pretty much the only place I can't control is the JDBC API, which I immediatly wrap with Joda DateTimes in the database layer before the application gets them.
    Reply to this Reply to original

  30. Re: +1 Joda-Time[ Go to top ]

    Yet another benefit to basing the new API on Joda Time is that we could start switching over sooner than later. If we knew that the next official Date and Time API was essentially going to be Joda Time we could just use the existing Joda Time library with the justification that the external dependency would eventually go away. It's not a big deal to change import statements later on. You guys must realize that this is Java's last chance to get date and time features "right". Sun's track record in this area is abysmal, so please just adopt the work of developers who've already created a compelling and complete solution. If nothing else, please do not ever create another class called "Date" that actually represents a specific point in *time* (hmmm... maybe you could call it DateTime ;-) ).
    Reply to this Reply to original

  31. Re: +1 Joda-Time[ Go to top ]

    Just to point out, I am also the project lead on Joda-Time. Stephen Colebourne Co-spec lead JSR 310
    Reply to this Reply to original

  32. This is how I want it[ Go to top ]

    I want an easy to use API, something like this: DateTime dt = new DateTime(2007, 1, 31); // Jan. 1st 2007 dt = new DateTime(); //returns today; dt = DateTime.TODAY(); //another alternative dt = new DateTime("MM-dd-yyyy"); //today in the given format dt = new DateTime("MM-dd-yyyy", 2007, 1, 31); dt = new DateTime(432747230933209L); //time in ms dt = new DateTime(new Time()); //see below String strDate = dt.getDateAsString("dd-MM-yyyy"); //enter the format you want. String strDate2 = dt.getDateAsString(); //returns the date in the default (locale) format settings. String strDate3 = dt.toString(); //hmmm...should this return something like DateTime@348932 or should it return dt.getDateAsString() ? DateTime dt2 = dt.addDays(10); //today += 10 days; dt2 = dt2.addDays(-400); // today -= 400 days dt2 = dt2.addMonths(20); //today += 20 months //etc. for week and year int days = dt2.getDays(new DateTime(2008, 1, 31)); //returns the length in days between dt and 2008-1-31 int months = dt2.getMonths(new DateTime(2008, 1, 31)); // returns the length in months between dt and 2008-1-31 //etc. for week and year long ms = dt.getTimeInMillis(); long ns = dt.getTimeInNanoSeconds(); int year = dt.getYear(); int month = dt.getMonth(); // 1-12 int day = dt.getDay(); // 1-31 int weeknumber = dt.getWeekNumber(); // 1-52 Time time = dt.getTime(); time = dt.getTime("HH:mm:ss:ms") //another alternative String strTime = time.getTimeAsString(); // for example: 13:45:16 or 1:45:16 PM time.addHours(100); //time += 100 hours //etc. for minutes, seconds and ms dt.setTime(time); + some other usefull methods of the Calendar API My request is not to use the Singleton pattern like in the Calendar API, because this gets annoying after a while.
    Reply to this Reply to original

  33. Re: This is how I want it[ Go to top ]

    +1
    Reply to this Reply to original

  34. Re: This is how I want it[ Go to top ]

    +1
    Reply to this Reply to original

  35. Re: JSR 310 - Date and Time API voted in[ Go to top ]

    After 15 years of Java, there is a hope to get a good Date API... Congratulations and please continue the good work! Cyril
    Reply to this Reply to original

  36. IBM's licensing disclaimer[ Go to top ]

    Given that Java has been open sourced it is now long past time for IBM to get rid of their verbose disclaimer about the licensing that they place on every one of their JCP votes. It's wording seems like a jab at Sun for not having open enough licensing -- which is odd considering Sun's Java is open source and IBM doesn't even give out the source code for their Java with their JVM to the best of my knowledge.
    Reply to this Reply to original

  37. Thanks for the feedback so far[ Go to top ]

    Thanks for the feedback so far. These requests will all get added to the requests area on the wiki (a TODO at present). I can't promise anything other than the EG will consider the requests. Speaking personally I find the request for cross-locale numeric-based date formats to be an interesting one.
    Reply to this Reply to original

  38. Re: JSR 310 - Date and Time API voted in[ Go to top ]

    I would be happy if we could do calendar.addDay(1) instead of calendar.add(Calendar.DATE , 1) or calendar.getMonth() instead of calendar.get(Calendar.MONTH). Calendar code looks rather ugly right now this way.
    Reply to this Reply to original

  39. First class entities[ Go to top ]

    Make both Date and Time first class entities. Discourage the attempt to turn it into a number. Allow to represent dates detached from timezones. 2006-12-01 is the same date everywhere in the world, unless *you* decide that you care for the timezone. Allow computation with dates and date ranges using all natural measures (timezones, years, months, days, hourse, minutes, seconds, milliseconds). Allow for easy holiday plugins. As for formatting: ISO Date formatting actually fits everyone who is using indian/arabian digits.
    Reply to this Reply to original

  40. Timezone by Location [and Time][ Go to top ]

    I thought Joda-Time had already got it pretty much right :) Some additional things I don't think it has: A way of getting the timezone applicable for a particular location (latitude, longitude). And given that these rules probably change over time, a way of getting the Timezone that was applicable at a particular location (latitude, longitude) at a specific instant (specified in either LocalTime or UTC).
    Reply to this Reply to original

  41. Re: JSR 310 - Date and Time API voted in[ Go to top ]

    1 - we should be able to operate and transfer the same object. I mean, these days, we are supposed to transfer the value from a Date to a Calendar, do the operations (change month, day, etc.), then retrieve a new Date. 2 - The changing operations should be done with the same pattern as BigInteger, BigDecimal. In other words, it should be possible to do: date.addDay(1).addMonth(1); Plus, each of these setting methods, like in BigDecimal, should return a new object with the changed value. Then we would be sure the Date objects in the new API is immutable. 3 - All APIs should be using the new Date API. This eternal backward compatibility will kill Java. When you have a major new release (like Java 5), previously deprecated stuff should disappear. 4 - When you add "1" to the day, you should get "1" added to the day, which is different from having 24h added to it. I got a few bugs with calendar.add(Calendar.DATE, 1), because of daylight savings change. Sometimes, you just care about the date, not the time. I don't know if it should be a different object to deal specifically with Date, and a specialization that deals with Date+Time.
    Reply to this Reply to original

  42. what developer wants[ Go to top ]

    1. new Date("31/01/2007", "UK_ENG", "/") should be good enough to get me a date with the value specified as string, with locale as one input and separator as other. something along these lines to make it simple. 2. checks for invalid date should be done at construction time. For example if i say new date("02/29/2007") thrwo me a invalid date exception. Dont make me do a check for month and year and leap year etc. 3. make date addition , sub traction easy. 4. make it easy to format is in any which way wihout going thru formaters and intermediate object creations. 5. Is this thread really read by anyone on the jsr ???
    Reply to this Reply to original

  43. Re: what developer wants[ Go to top ]

    Yes, we are tracking this thread :-) Michael Nascimento Santos JSR-310 spec lead https://genesis.dev.java.net/ http://weblogs.java.net/blog/mister__m/
    Reply to this Reply to original

  44. Yes we're watching[ Go to top ]

    And all requests here will get transferred to the Request page of the JSR wiki - http://wiki.java.net/bin/view/Projects/DateTimeAPI. Stephen Colebourne co-spec lead
    Reply to this Reply to original

  45. Date and Time separation[ Go to top ]

    We always have the need to compare only the day in a given Date, i.e. you want to find out if a Contract ends today. The problem is, that you have to care for time in a Date instance too, especially if you use .compare(..). An (optional) separation should be possible.
    Reply to this Reply to original

  46. other calendars[ Go to top ]

    more support for other calendars add persian jalali calendar support
    Reply to this Reply to original

  47. Re: JSR 310 - Date and Time API voted in[ Go to top ]

    A DateRange class alá Martin Fowler http://www.martinfowler.com/ap2/range.html toString and fromString that can take a pattern and a separator - no more dateAsDDMMYYYY_SlashSeparator(Date d), dateAsDDMMYY_DashSeparator(Date d), etc. A DateDiff class: Date d1 = new Date("13.06.2005"); Date d2 = new Date("01.02.2007"); DateDiff dd = new DateDiff(d1, d2); dd.Years = 1.666 // Difference in years dd.Year_on_Year = 2 // Difference between year fields dd.Months = 17.6 // Full difference in months dd.Month_on_Month = 8 // Difference btwn month fields dd.Days = 598 dd.Day_on_Day = -12 // Difference btwn day fields similar for TimeDiff using Hours, Minutes, Seconds toSql() - Converts to java.sql.Date fromSql() - Converts from java.sql.Date Add boolean field isWinterTime in BST/DST timezones. Maybe a method asSummerTime() would return a WinterTime date with the extra hour removed, return a SummerTime date as is? This could be useful for comparing intervals that could be in both Winter and SummerTime. Optionally a corresponding asWinterTime() method. Thanks for listening, Fintan
    Reply to this Reply to original

  48. Inspiration from Perl::DateTime for Joda/JSR 310?[ Go to top ]

    http://datetime.perl.org/ Dave Rolsky's Perl-based DateTime modules are the most complete, correct and convenient Date/Time libraries I've yet used. They include support for parsing, formatting, calendars, events, intervals, ICAL and cron-style date/spanning. I would most definitely consider reusing good stuff from Dave's fanatical work on correctness and completeness. How do they compare?
    Reply to this Reply to original

  49. JSR link[ Go to top ]

    Just for reference, this thread is now linked from the JSR wiki. http://wiki.java.net/bin/view/Projects/DateTimeRequests Stephen Colebourne Co-spec lead, JSR-310
    Reply to this Reply to original

  50. Re: JSR 310 - Date and Time API voted in[ Go to top ]

    Will JSR 310 try to solve issue of time/clock across different machines? e.g. JMS, clustered system, RMI or EJB We may have more then one machine and one clock on these system. And it is difficult to have a common relative time.
    Reply to this Reply to original

  51. Need a concept like Abutting Date/Week/Month and so on...[ Go to top ]

    Need a concept of abutting, which means the boundary conditions like between 2 dates/ between 2 months. For example, if i want to specify a date which is neither 31st December 2009 nor 1st January 2010. But in between these 2, when 31st Dec 2009 is changing to 1st January 2010. How do i specify this instant of time as a date. We need something like that. I can explain in detail if you call me or mail me on this number or email id. +91-9866487827 (91 is the code for india) amjathsharief at gmail dot com Thanks, Amjath
    Reply to this Reply to original

  52. some simple to use functionality[ Go to top ]

    It's just a date, could never understand why it was so complex to use in java. All I want is actually doable using dateFormat etc. but thats not very intuitive.

    I need something like

    Date dt = new Date(); //Today

    String str = dt.toString("MMYYDD");

    str = dt.toString("MM/DD/YYYY"); //get a date in required format

    Date dt = new Date("12/12/2009","MM/DD/YYYY"); // instantiate date with given values

    date dt1 = dt.substract(Date.MINUTE,340); //manipulate values

    some date functions to compare, deduct, add dates and get value in days, hours, minutes and seconds etc.

    There should be overloaded constructors which will take locale, timezone values. Sometime we need to specify those explicitely.

     

    Reply to this Reply to original