Well, when you create a MutableDateTime with an offset, then all
operations on that class have the offset applied.

Rounding to midnight (which is what the dayOfMonth rounding does) will
therefore produce a toString() at midnight. Rounding to nearest minute
will round within the offset/time-zone context, but that makes no
difference to the result.

If you need greater control than the standard classes are providing,
then you'll need to manage the offset yourself. See the DateTimeZone
class for methods to get the offset.

Stephen


On 22 December 2011 23:17, Shay Banon <kim...@gmail.com> wrote:
> Let me try and explain what I am trying to do, maybe I have gone the wrong
> way to try and achieve it. Basically, I have a list of utc millis since
> epoch, and I would like to build a histogram bucking them, but I want it to
> be built by also taking a custom time zone into account. The return value of
> each bucket should be skewed by the time zone to be millis since the epoch
> based on that time zone.
>
> I used MutableDateTime, initialized it with the relevant time zone, and then
> the rounding, and basically setMillis and getMillis for it. It works well
> with day rounding, but with minute rounding, I still get back the utc
> millis, and not ones epoch skewed by the time zone.
>
> The main reason for returning bucket start time in time zone based millis
> since epoch is to simplify graphing the results.
>
> Does that make sense? Is there a better way to do it?
>
>
> On Fri, Dec 23, 2011 at 12:13 AM, Stephen Colebourne <scolebou...@joda.org>
> wrote:
>>
>> When you choose dayOfMonth, you are asking to round to the nearest
>> day, where as with minuteOfHour you are asking to round to the nearest
>> minute. The rounding occurs relative to the offset.
>>
>> The millis value for the date is simply a reflection of the offset.
>> The rounding applies to the local date time, which is why both the
>> +01:00 and UTC offsets print a time of midnight.
>>
>> Stephen
>>
>> On 22 December 2011 21:13, Shay Banon <kim...@gmail.com> wrote:
>> > Heya,
>> >
>> >    I got this strange behavior with rounding and timezone. Depending on
>> > the
>> > type of rounding (dayOfMonth vs. minuteOfHour) I am getting different
>> > results for the same rounded value. The following code runs with
>> > dayOfMonth:
>> >
>> >         MutableDateTime time = new MutableDateTime(DateTimeZone.UTC);
>> >         time.setZone(DateTimeZone.forOffsetHours(1));
>> >         time.setRounding(time.getChronology().dayOfMonth(),
>> > MutableDateTime.ROUND_FLOOR);
>> >
>> >         MutableDateTime utcTime = new MutableDateTime(DateTimeZone.UTC);
>> >         utcTime.setRounding(utcTime.getChronology().dayOfMonth(),
>> > MutableDateTime.ROUND_FLOOR);
>> >
>> >         time.setMillis(0);
>> >         utcTime.setMillis(0);
>> >         System.out.println("time: " + time + ", utc " + utcTime);
>> >         System.out.println("time_millis: " + time.getMillis() + ",
>> > utc_millis " + utcTime.getMillis());
>> >
>> > And the output shows that the time millis differ between the utc one,
>> > and
>> > the time zone one. On the other hand, just changing to round based on
>> > minuteOfHour, results in the millis between the two to be the same:
>> >
>> >         MutableDateTime time = new MutableDateTime(DateTimeZone.UTC);
>> >         time.setZone(DateTimeZone.forOffsetHours(1));
>> >         time.setRounding(time.getChronology().minuteOfHour(),
>> > MutableDateTime.ROUND_FLOOR);
>> >
>> >         MutableDateTime utcTime = new MutableDateTime(DateTimeZone.UTC);
>> >         utcTime.setRounding(utcTime.getChronology().minuteOfHour(),
>> > MutableDateTime.ROUND_FLOOR);
>> >
>> >         time.setMillis(0);
>> >         utcTime.setMillis(0);
>> >         System.out.println("time: " + time + ", utc " + utcTime);
>> >         System.out.println("time_millis: " + time.getMillis() + ",
>> > utc_millis " + utcTime.getMillis());
>> >
>> >
>> > I must be missing something obvious, but I don't understand why the
>> > results
>> > would be different between the two runs? The results of the two runs
>> > should
>> > be the same (and I think they all should have 0 as millis, no?).
>> >
>> > -shay.banon
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Write once. Port to many.
>> > Get the SDK and tools to simplify cross-platform app development. Create
>> > new or port existing apps to sell to consumers worldwide. Explore the
>> > Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
>> > http://p.sf.net/sfu/intel-appdev
>> > _______________________________________________
>> > Joda-interest mailing list
>> > Joda-interest@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/joda-interest
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Write once. Port to many.
>> Get the SDK and tools to simplify cross-platform app development. Create
>> new or port existing apps to sell to consumers worldwide. Explore the
>> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
>> http://p.sf.net/sfu/intel-appdev
>> _______________________________________________
>> Joda-interest mailing list
>> Joda-interest@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>
>
>
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________
> Joda-interest mailing list
> Joda-interest@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/joda-interest
>

------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
Joda-interest mailing list
Joda-interest@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/joda-interest

Reply via email to