Right, I saw that toString handles it nicely, but I still need the millis.
Its basically an API that returns bucketed results with counts, and the
bucket value is millis for simplicity (so the user won't need to parse a
formatted string). Is there a way to get the "correct" millis?
On Thu, Dec 29, 2011 at 7:48 PM, Stephen Colebourne <scolebou...@joda.org>wrote:
> Internally, J-T calculates using "local millis" which is a count based
> on epoch millis with the offset removed. This is in effect identical
> to UTC.
>
> After you setMillis(0), you can do a toString(), and you will see the
> time is 01:00. When this is rounded to the nearest day you get a time
> of 00:00 (which happens to be -3600000 in UTC millis).
>
> But rounding a time of 01:00 to the nearest minute will not change
> anything, and gives 01:00.
>
> The problem is that you are focussing on getting the millis, rather
> than on the toString() value, which is correct.
>
> Stephen
>
>
> On 29 December 2011 17:02, Shay Banon <kim...@gmail.com> wrote:
> > Grr, I started to try and build something that would do the rounding I
> need,
> > but I feel like I might be missing something in Joda that will help me
> and
> > not cause me to write all this code.
> >
> > Recap of what I am trying to do: Have a list of UTC millis, and want to
> > bucket them based on rounding and time zone. The buckets can be either
> UTC
> > millis rounded, or time zone offset, I don't mind, but obviously,
> rounding
> > should take timezone into account.
> >
> > Going back to my first sample, when I use dayOfMonth:
> >
> > MutableDateTime time = new MutableDateTime(DateTimeZone.UTC);
> > time.setZone(DateTimeZone.forOffsetHours(1));
> > time.setRounding(time.getChronology().dayOfMonth(),
> > MutableDateTime.ROUND_FLOOR);
> > time.setMillis(0);
> > time.getMilli();
> >
> > I get back -3600000, which is basically 1 hour before 0. What happens is
> > that the millis are offseted by the time zone, then floored by day, and
> > then the timezone is applied again. The result is not UTC.
> >
> > On the other hand, when I use minutOfHour instead of day, I get back 0,
> > which is UTC.
> >
> > I need something that is consistent regardless of the rounding applied
> (day,
> > minute, hour), is there a way to do it with Joda "easily", or do I need
> to
> > write something myself, that does not convert back from local to UTC if
> > using certain rounding?
> >
> >
> >
> >
> > On Thu, Dec 29, 2011 at 11:09 AM, Stephen Colebourne <
> scolebou...@joda.org>
> > wrote:
> >>
> >> While I haven't tested it, I'd expect something like that to work (and
> >> be reasonably performant). Best advice is to write some decent unit
> >> tests and check it that way!
> >> Stephen
> >>
> >> On 28 December 2011 21:42, Shay Banon <kim...@gmail.com> wrote:
> >> > 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
> >> >
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> 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
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > 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
> >
>
>
> ------------------------------------------------------------------------------
> 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
>
------------------------------------------------------------------------------
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
