> I am +1 for changing to longs and deprecating. +1
> -----Original Message----- > From: Phil Steitz [mailto:[EMAIL PROTECTED] > Sent: Monday, December 22, 2003 11:54 > To: Jakarta Commons Developers List > Subject: Re: [lang] DateUtils constants should be long > > Brian S O'Neill wrote: > > There's a difference between specifying a unit of time to sleep vs > > defining a constant. The JRE APIs are inconsistent. The google search > > brings up: > > > > http://java.sun.com/j2se/1.3/docs/api/java/awt/Robot.html > > > > which accepts millisecond sleep times as ints. > > > Then there's: > > > > http://java.sun.com/j2se/1.3/docs/api/java/net/Socket.htm > > > > which accepts millisecond timeouts as defined by ints. Also: > > > > > http://java.sun.com/j2se/1.4.2/docs/api/javax/swing/AbstractButton.html#do > Click(int) > > > > All of these are examples where a value greater than integer.MAX_VALUE > would not make sense (the first one in fact throws if the value is > > 60,000). As indicated in the bug report, there are natural applications > of the DateUtils constants where overflows will happen. The point is that > it is expected that these contants will be used in computations. > > So what is the verdict here, folks? I would like to either make the > change (including deprecation) or close the ticket as WONTFIX. I am +1 > for changing to longs and deprecating. > > Phil > > > > Gary Gregory wrote: > > > >> Brian: "I think that constant values should always be stored using the > >> type > >> that best represents them" > >> > >> Perhaps the best reason for switching [lang] to using a long to > represent > >> milliseconds is that JRE APIs do so. For example: > >> > http://java.sun.com/j2se/1.3/docs/api/java/lang/System.html#currentTimeMil > li > >> > >> s() > >> > >> http://java.sun.com/j2se/1.3/docs/api/java/lang/Object.html#wait(long) > >> > >> More: > >> http://www.google.com/search?hl=en&lr=&ie=UTF-8&oe=utf- > 8&as_qdr=all&q=millis > >> > >> > econds+site%3Ajava.sun.com+%2Fj2se%2F1.3%2Fdocs%2Fapi&btnG=Google+Search > >> > >> Gary > >> > >> > >> > >>> -----Original Message----- > >>> From: Brian S O'Neill [mailto:[EMAIL PROTECTED] > >>> Sent: Sunday, December 21, 2003 10:02 > >>> To: Jakarta Commons Developers List > >>> Subject: Re: [lang] DateUtils constants should be long > >>> > >>> The DateTimeConstants class in Joda-time originally defined these > kinds > >>> of constants as ints. Then they switched to longs, however, some > classes > >>> that depended on these constants were required to downcast to ints. > >>> Although it caused no harm since the values can fit in an int, I was > >>> concerned that some users might think that storing the value in a long > >>> is required. > >>> > >>> As of now, the constants are defined as ints again. If you are using > >>> these constants for performing calculations, you may need to ensure > that > >>> the constant is cast to a long. But if you're doing calculations, then > >>> you need to be careful anyhow, and Joda-time should contain enough > >>> functionality such that you won't need to perform your own > calculations. > >>> > >>> By storing the constant as a long, an assumption is made about how the > >>> user is going to be using it. What if the user needs to do some > >>> floating-point calculations? Maybe they'll forget to cast the int or > >>> long into a double? Should the constant be then stored as a double > >>> instead? It fits. Again then this gives the impression that the > >>> constants must be represented as this type, and downcasts may cause > loss > >>> of precision. > >>> > >>> Whenever doing calculations, you always need to be aware of the > >>> precision requirements. I think that constant values should always be > >>> stored using the type that best represents them, although don't bother > >>> using byte or short since the Java platform always casts those into > >>> ints. Users of these constants are responsible for upcasting them into > a > >>> type that is required for their calculation. > >>> > >>> Stephen Colebourne wrote: > >>> > >>> > >>> > >>>> Hmmm, I hadn't thought about deprecation. But I think we do have to. > >>>> > >>> > >>> Bother. > >>> > >>> > >>>> Stephen > >>>> > >>>> ----- Original Message ----- > >>>> From: "Gary Gregory" <[EMAIL PROTECTED]> > >>>> > >>>> > >>>> > >>>> > >>>>> Hm... I thought the proposal was just to change the types from int > to > >>>>> > >>> > >>> long > >>> > >>> > >>>>> on the existing fields as opposed to creating new fields. > >>>>> > >>>>> Obviously this would not be backwards compatible but if we are > saying > >>>>> > >>> > >>> that > >>> > >>> > >>>>> the fact that they are ints is, in actuality, a "bug", then, maybe, > >>>>> > >>>>> > >>>>> > >>>> > >>>> perhaps, > >>>> > >>>> > >>>> > >>>> > >>>>> it would be acceptable to break call site... arg, probably not. > >>>>> > >>>>> It certainly would fix the client code that is just expressions (as > >>>>> > >>>>> > >>>>> > >>>> > >>>> opposed > >>>> > >>>> > >>>> > >>>> > >>>>> to assignments to ints which would no longer compile). It's never > nice > >>>>> > >>> > >>> to > >>> > >>> > >>>>> break client code of course and deprecation is just for that > purpose. > >>>>> > >>>>> So, all of that round and round to say I agree with you in the end! > >>>>> ;-) > >>>>> > >>>>> Would anyone else care to comment? > >>>>> > >>>>> Gary > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Phil Steitz [mailto:[EMAIL PROTECTED] > >>>>>> Sent: Saturday, December 20, 2003 15:47 > >>>>>> To: Jakarta Commons Developers List > >>>>>> Subject: Re: DO NOT REPLY [Bug 25627] - [lang] DateUtils constants > >>>>>> > >>>>>> > >>>>>> > >>>> > >>>> should > >>>> > >>>> > >>>> > >>>> > >>>>>> be long > >>>>>> > >>>>>> Gary Gregory wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Looking for a volunteer (Stephen? ;-) I as I in ultra-busy mode... > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> I will volunteer for this. I assume that since these are (2.0 > >>>>>> > >>> > >>> released) > >>> > >>> > >>>>>> public fields, we need to deprecate and rename. I would use > >>>>>> > >>> > >>> MILLIS_PER_* > >>> > >>> > >>>>>> for the new names. Sound OK? > >>>>>> > >>>>>> Phil > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Gary > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > >>>>>>>> Sent: Thursday, December 18, 2003 12:53 > >>>>>>>> To: [EMAIL PROTECTED] > >>>>>>>> Subject: DO NOT REPLY [Bug 25627] - [lang] DateUtils constants > >>>>>>>> should > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>> > >>>> be > >>>> > >>>> > >>>> > >>>> > >>>>>>>> long > >>>>>>>> > >>>>>>>> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG > >>>>>>>> RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT > >>>>>>>> <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25627>. > >>>>>>>> ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND > >>>>>>>> INSERTED IN THE BUG DATABASE. > >>>>>>>> > >>>>>>>> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25627 > >>>>>>>> > >>>>>>>> [lang] DateUtils constants should be long > >>>>>>>> > >>>>>>>> [EMAIL PROTECTED] changed: > >>>>>>>> > >>>>>>>> What |Removed |Added > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>> > >>>>>> ------------------------------------------------------------------- > ---- > >>>>>> > >>>>>> > >>> > >>> - > >>> > >>> > >>>>>> -- > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>>> -- > >>>>>>>> Status|NEW |ASSIGNED > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> ------- Additional Comments From [EMAIL PROTECTED] 2003-12- > 18 > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>> > >>>>>> 20:52 > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>>> ------- > >>>>>>>> Indeed, since these values express milliseconds and APIs which > take > >>>>>>>> > >>> > >>> or > >>> > >>> > >>>>>>>> return > >>>>>>>> millisconds usually do so a longs. > >>>>>>>> > >>>>>>>> ----------------------------------------------------------------- > ---- > >>>>>>>> > >>>>>>>> To unsubscribe, e-mail: commons-dev- > [EMAIL PROTECTED] > >>>>>>>> For additional commands, e-mail: > >>>>>>>> [EMAIL PROTECTED] > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>> > >>>>>> ------------------------------------------------------------------- > -- > >>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>>>> For additional commands, e-mail: commons-dev- > [EMAIL PROTECTED] > >>>>>> > >>>>>> > >>>>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>> For additional commands, e-mail: [EMAIL PROTECTED] > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >> > >> > >> > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED]
