Heya,
Yea, I see the problem with converting back to UTC after the rounding.
But, if I want to keep it in millis since the epoch offset by time zone,
will this code work ok?:
DateTimeZone timeZone = <<some timezone>>
long utcMillis = <<some number>>
MutableDateTime time = new MutableDateTime(DateTimeZone.UTC);
time.setRounding(time.getChronology().minuteOfDay(),
MutableDateTime.ROUND_FLOOR);
time.setMillis(utcMillis + timeZone.getOffset(utcMillis));
long actualValue = time.getMillis();
I am still using MutableDateTime with UTC, but passing it the offset millis
so it will do the rounding for me. I can work around not even using
MutableDateTime by using DateTimeField from the chronology directly and
calling the correct round method.
Does that make sense?
On Wed, Dec 28, 2011 at 1:25 PM, Stephen Colebourne <scolebou...@joda.org>wrote:
> 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
>
------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
Joda-interest mailing list
Joda-interest@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/joda-interest
