Its a simplification that I think leads to a clearer API overall. Of
course thats debateable, but I think this use case is pretty small to
complicate the whloe API with. Plus, I wouldn't change it anyway as it
would be backwards incompatble.
Stephen
On 28 September 2011 18:05, Bård Dybwad Kristensen <baa...@gmail.com> wrote:
> Hi
>>
>> The class Interval basically consists of three fields:
>>
>> /** The chronology of the interval */
>> private volatile Chronology iChronology;
>> /** The start of the interval */
>> private volatile long iStartMillis;
>> /** The end of the interval */
>> private volatile long iEndMillis;
>>
>> and a lot of different ways of constructing the object. What I find
>> strange is that there is only one Chronology. I think there should be two
>> Chronologies, one for the start and one for the end. They will be the same
>> for all ways of constructing the object except for the constructor
>> public Interval(ReadableInstant start, ReadableInstant end),
>> where each argument has it's own chronology. I really think that these
>> two chronologies should be stored in the object, so that it is possible to
>> get the start and end with their original chronologies from the interval at
>> a later stage. As it is now, the chronology of the 'end' argument will be
>> set to the same as for the 'start' argument.
>> Consider the code:
>>
>> @Test
>> public void intervalTest() {
>> DateTime start = new
>> LocalDateTime("2011-01-01T12:30:00").toDateTime(DateTimeZone.forID("Europe/Paris"));
>> DateTime end = new
>> LocalDateTime("2011-01-01T18:30:00").toDateTime(DateTimeZone.forID("Asia/Dubai"));
>> Interval interval = new Interval(start, end);
>> System.out.println("start:\t\t\t" + start);
>> System.out.println("end:\t\t\t" + end);
>> System.out.println("interval.getStart():\t" + interval.getStart());
>> System.out.println("interval.getEnd():\t" + interval.getEnd());
>> }
>>
>> Result:
>> start: 2011-01-01T12:30:00.000+01:00
>> end: 2011-01-01T18:30:00.000+04:00
>> interval.getStart(): 2011-01-01T12:30:00.000+01:00
>> interval.getEnd(): 2011-01-01T15:30:00.000+01:00
>> The fact that the end date time originally had TimeZone "Asia/Dubai" is
>> gone forever.
>> Should it really be this way?
>> Any comments, anyone?
>> regards,
>> Bård Dybwad Kristensen
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Joda-interest mailing list
> Joda-interest@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/joda-interest
>
>
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Joda-interest mailing list
Joda-interest@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/joda-interest
