First, thanks for sticking with me :). I think I might need to go down the
custom code route, wanted to verify if my logic is sound. Rounding based on
zone is done in ZoneChrono, basically, this:
if (iTimeField) {
int offset = getOffsetToAdd(instant);
instant = iField.roundFloor(instant + offset);
return instant - offset;
} else {
long localInstant = iZone.convertUTCToLocal(instant);
localInstant = iField.roundFloor(localInstant);
return iZone.convertLocalToUTC(localInstant, false,
instant);
}
But, this does not work well in my case. If its iTimeFIeld, then it will
return the UTC millis, but if not, then there is no need to
convertLocalToUTC, since its already in UTC millis because of the "bigger"
rounding. Is that correct?
On Fri, Dec 30, 2011 at 1:13 AM, Stephen Colebourne <[email protected]>wrote:
> Perhaps DateTimeZone.convertUTCToLocal(utcMillis) might be the method you
> want?
>
> Or, MutableDateTime.setZoneRetainMillis(UTC) ?
>
> both will effectively get the "local millis".
>
> Stephen
>
> On 29 December 2011 18:23, Shay Banon <[email protected]> wrote:
> > 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 <
> [email protected]>
> > 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 <[email protected]> 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
> >> > <[email protected]>
> >> > 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 <[email protected]> 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
> >> >> > <[email protected]>
> >> >> > 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 <[email protected]> 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
> >> >> >> > <[email protected]>
> >> >> >> > 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 <[email protected]>
> 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
> >> >> >> >> > [email protected]
> >> >> >> >> > 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
> >> >> >> >> [email protected]
> >> >> >> >> 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
> >> >> >> > [email protected]
> >> >> >> > 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
> >> >> >> [email protected]
> >> >> >> 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
> >> >> > [email protected]
> >> >> > 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
> >> >> [email protected]
> >> >> 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
> >> > [email protected]
> >> > 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
> >> [email protected]
> >> 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
> > [email protected]
> > 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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/joda-interest
