-
JSR 310 - Date and Time API voted in (51 messages)
- Posted by: Stephen Colebourne
- Posted on: February 14 2007 10:52 EST
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?Threaded Messages (51)
- Re: JSR 310 - Date and Time API voted in by John Murray on February 14 2007 11:19 EST
- Changes to SimpleDateFormat by Bruce Atherton on February 15 2007 20:50 EST
- Re: Changes to SimpleDateFormat by Georg Mueller on February 16 2007 05:11 EST
- Re: JSR 310 - Date and Time API voted in by Mass Dosage on February 21 2007 02:48 EST
- Changes to SimpleDateFormat by Bruce Atherton on February 15 2007 20:50 EST
- intelligent date and time parsing by Holger Engels on February 14 2007 11:28 EST
- Re: intelligent date and time parsing by Cédrik LIME on February 14 2007 11:38 EST
- dateranges by Amin Mansuri on February 14 2007 12:42 EST
- Re: dateranges by augustientje bloem on February 18 2007 08:25 EST
- Method to return Daylight transition date by Naveen Kamrudeen on February 14 2007 13:05 EST
- Re: Method to return Daylight transition date by Peter Monks on February 14 2007 15:37 EST
- Re: JSR 310 - Date and Time API voted in by George Coller on February 14 2007 15:47 EST
- Re: JSR 310 - Date and Time API voted in by Ryan Breidenbach on February 14 2007 17:38 EST
- Re: JSR 310 - Date and Time API voted in by Neil Bartlett on February 14 2007 16:09 EST
- Cleaner API for TimeZone and defining daylight savings by Andre Piwoni on February 14 2007 17:05 EST
- XmlGregorianCalendar... by Lucas Jordan on February 14 2007 22:51 EST
- Context by Nebojsa Vasiljevic on February 15 2007 06:48 EST
-
Re: Context by George Coller on February 15 2007 09:25 EST
-
Re: Context by Nebojsa Vasiljevic on February 15 2007 02:54 EST
-
Times change by Derek Alexander on February 15 2007 03:41 EST
- Re: Times change by Karl Banke on February 16 2007 05:47 EST
-
Times change by Derek Alexander on February 15 2007 03:41 EST
-
Re: Context by Nebojsa Vasiljevic on February 15 2007 02:54 EST
-
Re: Context by George Coller on February 15 2007 09:25 EST
- Re: XmlGregorianCalendar... by Bryan Headley on February 15 2007 13:21 EST
- Context by Nebojsa Vasiljevic on February 15 2007 06:48 EST
- Date, Time and Timestamp separation by Ido Tzang on February 15 2007 01:17 EST
- Output formating by Nils Myklebust on February 15 2007 04:19 EST
- Umm, nope... by Tatu Saloranta on February 20 2007 15:22 EST
- Interval by Nils Myklebust on February 15 2007 04:24 EST
- Just copy Joda-Time by Brett Elliott on February 15 2007 06:27 EST
-
+1 Joda-Time by k s on February 16 2007 03:09 EST
- Re: +1 Joda-Time by Mike Quilleash on February 16 2007 05:16 EST
-
Re: +1 Joda-Time by Ryan Holmes on February 17 2007 12:17 EST
-
Re: +1 Joda-Time by Stephen Colebourne on February 17 2007 05:54 EST
-
This is how I want it by Eleganti Roseburner on February 18 2007 05:42 EST
- Re: This is how I want it by David McCoy on February 20 2007 10:17 EST
- Re: This is how I want it by Matt West on February 21 2007 03:34 EST
-
This is how I want it by Eleganti Roseburner on February 18 2007 05:42 EST
-
Re: +1 Joda-Time by Stephen Colebourne on February 17 2007 05:54 EST
-
+1 Joda-Time by k s on February 16 2007 03:09 EST
- Just copy Joda-Time by Brett Elliott on February 15 2007 06:27 EST
- Re: JSR 310 - Date and Time API voted in by Cyril Gambis on February 15 2007 05:02 EST
- IBM's licensing disclaimer by Jess Holle on February 15 2007 06:29 EST
- Thanks for the feedback so far by Stephen Colebourne on February 15 2007 09:20 EST
- Re: JSR 310 - Date and Time API voted in by Dennis Bekkering on February 15 2007 11:27 EST
- First class entities by Karl Banke on February 15 2007 11:43 EST
- Timezone by Location [and Time] by Derek Alexander on February 15 2007 13:29 EST
- Re: JSR 310 - Date and Time API voted in by Rodrigo Cana on February 15 2007 14:08 EST
- what developer wants by shawn spencer on February 16 2007 01:49 EST
- Re: what developer wants by Michael Santos on February 16 2007 06:26 EST
-
Yes we're watching by Stephen Colebourne on February 16 2007 06:39 EST
- Date and Time separation by Reik Schatz on February 16 2007 06:56 EST
-
Yes we're watching by Stephen Colebourne on February 16 2007 06:39 EST
- Re: what developer wants by Michael Santos on February 16 2007 06:26 EST
- other calendars by Arash Rajaeeyan on February 20 2007 15:43 EST
- Re: JSR 310 - Date and Time API voted in by Fintan Conway on February 22 2007 07:02 EST
- Inspiration from Perl::DateTime for Joda/JSR 310? by Server Side on February 23 2007 08:06 EST
- JSR link by Stephen Colebourne on February 26 2007 19:44 EST
- Re: JSR 310 - Date and Time API voted in by Dennis Cheung on September 08 2007 07:15 EDT
- Need a concept like Abutting Date/Week/Month and so on... by AMJATH SHARIEF on December 12 2009 03:17 EST
- some simple to use functionality by Parveen Kumar on May 06 2010 19:23 EDT
-
Re: JSR 310 - Date and Time API voted in[ Go to top ]
- Posted by: John Murray
- Posted on: February 14 2007 11:19 EST
- in response to Stephen Colebourne
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 -
Changes to SimpleDateFormat[ Go to top ]
- Posted by: Bruce Atherton
- Posted on: February 15 2007 20:50 EST
- in response to John Murray
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. -
Re: Changes to SimpleDateFormat[ Go to top ]
- Posted by: Georg Mueller
- Posted on: February 16 2007 05:11 EST
- in response to Bruce Atherton
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 -
Re: JSR 310 - Date and Time API voted in[ Go to top ]
- Posted by: Mass Dosage
- Posted on: February 21 2007 02:48 EST
- in response to John Murray
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. -
intelligent date and time parsing[ Go to top ]
- Posted by: Holger Engels
- Posted on: February 14 2007 11:28 EST
- in response to Stephen Colebourne
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 ... -
Re: intelligent date and time parsing[ Go to top ]
- Posted by: Cédrik LIME
- Posted on: February 14 2007 11:38 EST
- in response to Holger Engels
I'll add to this: please include ISO 8601 DateTime processing too! ________ MessAdmin, J2EE monitoring made easy! -
dateranges[ Go to top ]
- Posted by: Amin Mansuri
- Posted on: February 14 2007 12:42 EST
- in response to Stephen Colebourne
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.. -
Re: dateranges[ Go to top ]
- Posted by: augustientje bloem
- Posted on: February 18 2007 08:25 EST
- in response to Amin Mansuri
I really like .net's DateRanges. You can do things like:
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.
int milliseconds = (endDate-startDate).totalMilliseconds();
or you can ask for it in days, weeks, years..etc.. -
Method to return Daylight transition date[ Go to top ]
- Posted by: Naveen Kamrudeen
- Posted on: February 14 2007 13:05 EST
- in response to Stephen Colebourne
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. -
Re: Method to return Daylight transition date[ Go to top ]
- Posted by: Peter Monks
- Posted on: February 14 2007 15:37 EST
- in response to Naveen Kamrudeen
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 -
Re: JSR 310 - Date and Time API voted in[ Go to top ]
- Posted by: George Coller
- Posted on: February 14 2007 15:47 EST
- in response to Stephen Colebourne
JSR 310 - Date and Time API, has now passed its first hurdle. There were 15 yes votes and 1 non-vote.
I'd be happy just to have immutable Date objects
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? -
Re: JSR 310 - Date and Time API voted in[ Go to top ]
- Posted by: Ryan Breidenbach
- Posted on: February 14 2007 17:38 EST
- in response to George Coller
I'd be happy just to have immutable Date objects
+1 -
Re: JSR 310 - Date and Time API voted in[ Go to top ]
- Posted by: Neil Bartlett
- Posted on: February 14 2007 16:09 EST
- in response to Stephen Colebourne
What a surprise, the non-voter was Borland. Have they just given up on the JCP entirely? -
Cleaner API for TimeZone and defining daylight savings[ Go to top ]
- Posted by: Andre Piwoni
- Posted on: February 14 2007 17:05 EST
- in response to Stephen Colebourne
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. -
XmlGregorianCalendar...[ Go to top ]
- Posted by: Lucas Jordan
- Posted on: February 14 2007 22:51 EST
- in response to Stephen Colebourne
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! -
Context[ Go to top ]
- Posted by: Nebojsa Vasiljevic
- Posted on: February 15 2007 06:48 EST
- in response to Lucas Jordan
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 -
Re: Context[ Go to top ]
- Posted by: George Coller
- Posted on: February 15 2007 09:25 EST
- in response to Nebojsa Vasiljevic
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? -
Re: Context[ Go to top ]
- Posted by: Nebojsa Vasiljevic
- Posted on: February 15 2007 14:54 EST
- in response to George Coller
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 -
Times change[ Go to top ]
- Posted by: Derek Alexander
- Posted on: February 15 2007 15:41 EST
- in response to Nebojsa Vasiljevic
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. -
Re: Times change[ Go to top ]
- Posted by: Karl Banke
- Posted on: February 16 2007 05:47 EST
- in response to Derek Alexander
Your argument reminds me of java.util back in the day when I learnt Java.
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.
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. -
Re: XmlGregorianCalendar...[ Go to top ]
- Posted by: Bryan Headley
- Posted on: February 15 2007 13:21 EST
- in response to Lucas Jordan
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. -
Date, Time and Timestamp separation[ Go to top ]
- Posted by: Ido Tzang
- Posted on: February 15 2007 01:17 EST
- in response to Stephen Colebourne
I'd like to see better Date, Time and Timestamp separation, like in java.sql today. -
Output formating[ Go to top ]
- Posted by: Nils Myklebust
- Posted on: February 15 2007 04:19 EST
- in response to Stephen Colebourne
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. -
Umm, nope...[ Go to top ]
- Posted by: Tatu Saloranta
- Posted on: February 20 2007 15:22 EST
- in response to Nils Myklebust
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. -
Interval[ Go to top ]
- Posted by: Nils Myklebust
- Posted on: February 15 2007 04:24 EST
- in response to Stephen Colebourne
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. -
Just copy Joda-Time[ Go to top ]
- Posted by: Brett Elliott
- Posted on: February 15 2007 06:27 EST
- in response to Nils Myklebust
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. :) -
+1 Joda-Time[ Go to top ]
- Posted by: k s
- Posted on: February 16 2007 15:09 EST
- in response to Brett Elliott
Joda-Time has been refined and optimized already. No need to reinvent the wheel again. -
Re: +1 Joda-Time[ Go to top ]
- Posted by: Mike Quilleash
- Posted on: February 16 2007 17:16 EST
- in response to k s
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. -
Re: +1 Joda-Time[ Go to top ]
- Posted by: Ryan Holmes
- Posted on: February 17 2007 00:17 EST
- in response to k s
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 ;-) ). -
Re: +1 Joda-Time[ Go to top ]
- Posted by: Stephen Colebourne
- Posted on: February 17 2007 05:54 EST
- in response to Ryan Holmes
Just to point out, I am also the project lead on Joda-Time. Stephen Colebourne Co-spec lead JSR 310 -
This is how I want it[ Go to top ]
- Posted by: Eleganti Roseburner
- Posted on: February 18 2007 05:42 EST
- in response to Stephen Colebourne
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. -
Re: This is how I want it[ Go to top ]
- Posted by: David McCoy
- Posted on: February 20 2007 10:17 EST
- in response to Eleganti Roseburner
+1 -
Re: This is how I want it[ Go to top ]
- Posted by: Matt West
- Posted on: February 21 2007 03:34 EST
- in response to Eleganti Roseburner
+1 -
Re: JSR 310 - Date and Time API voted in[ Go to top ]
- Posted by: Cyril Gambis
- Posted on: February 15 2007 05:02 EST
- in response to Stephen Colebourne
After 15 years of Java, there is a hope to get a good Date API... Congratulations and please continue the good work! Cyril -
IBM's licensing disclaimer[ Go to top ]
- Posted by: Jess Holle
- Posted on: February 15 2007 06:29 EST
- in response to Stephen Colebourne
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. -
Thanks for the feedback so far[ Go to top ]
- Posted by: Stephen Colebourne
- Posted on: February 15 2007 09:20 EST
- in response to Stephen Colebourne
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. -
Re: JSR 310 - Date and Time API voted in[ Go to top ]
- Posted by: Dennis Bekkering
- Posted on: February 15 2007 11:27 EST
- in response to Stephen Colebourne
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. -
First class entities[ Go to top ]
- Posted by: Karl Banke
- Posted on: February 15 2007 11:43 EST
- in response to Stephen Colebourne
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. -
Timezone by Location [and Time][ Go to top ]
- Posted by: Derek Alexander
- Posted on: February 15 2007 13:29 EST
- in response to Stephen Colebourne
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). -
Re: JSR 310 - Date and Time API voted in[ Go to top ]
- Posted by: Rodrigo Cana
- Posted on: February 15 2007 14:08 EST
- in response to Stephen Colebourne
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. -
what developer wants[ Go to top ]
- Posted by: shawn spencer
- Posted on: February 16 2007 01:49 EST
- in response to Stephen Colebourne
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 ??? -
Re: what developer wants[ Go to top ]
- Posted by: Michael Santos
- Posted on: February 16 2007 06:26 EST
- in response to shawn spencer
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/ -
Yes we're watching[ Go to top ]
- Posted by: Stephen Colebourne
- Posted on: February 16 2007 06:39 EST
- in response to Michael Santos
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 -
Date and Time separation[ Go to top ]
- Posted by: Reik Schatz
- Posted on: February 16 2007 06:56 EST
- in response to Stephen Colebourne
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. -
other calendars[ Go to top ]
- Posted by: Arash Rajaeeyan
- Posted on: February 20 2007 15:43 EST
- in response to Stephen Colebourne
more support for other calendars add persian jalali calendar support -
Re: JSR 310 - Date and Time API voted in[ Go to top ]
- Posted by: Fintan Conway
- Posted on: February 22 2007 07:02 EST
- in response to Stephen Colebourne
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 -
Inspiration from Perl::DateTime for Joda/JSR 310?[ Go to top ]
- Posted by: Server Side
- Posted on: February 23 2007 08:06 EST
- in response to Stephen Colebourne
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? -
JSR link[ Go to top ]
- Posted by: Stephen Colebourne
- Posted on: February 26 2007 19:44 EST
- in response to Stephen Colebourne
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 -
Re: JSR 310 - Date and Time API voted in[ Go to top ]
- Posted by: Dennis Cheung
- Posted on: September 08 2007 07:15 EDT
- in response to Stephen Colebourne
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. -
Need a concept like Abutting Date/Week/Month and so on...[ Go to top ]
- Posted by: AMJATH SHARIEF
- Posted on: December 12 2009 03:17 EST
- in response to Stephen Colebourne
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 -
some simple to use functionality[ Go to top ]
- Posted by: Parveen Kumar
- Posted on: May 06 2010 19:23 EDT
- in response to Stephen Colebourne
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.