We already separate persistence and aggregation in that aggregation engine is agnostic re which period type a period/datavalue has, it just looks at the start/end-date. I think the issue with Samuel's request is that people want to persist data for a fiscal year period.
On Wed, Feb 23, 2011 at 5:06 PM, Bob Jolliffe <[email protected]> wrote: > Hi Jason > > This is quite a tricky requirement and there different approaches > which might work. My gut instinct is to have a single "internal" > timebase to the system and to deal with different calendaring > requirements on the aggregation, presentation and output side. So for > example a datavalue persisted with period 2010-Q1 would always refer > to Jan-Mar for that year, But in a report requiring USGOV-FY (please > don't just say fiscal year - all countries have a fiscal year and they > don't all run from Sep-Oct! Ah, I see Samuel has already come in on > this.) that same period would be presented (and aggregated) as > 2010-Q2. There would be some complexities to solve here, but would > have the benefit that, at least internally, a time period is always a > comparable time period. > > If we are going to mess around creating (yet more) custom period types > then one way might be to add an attribute to the period class > indicating the preferred calendar type to be used in aggregation and > reporting. So any period eg 2007 or 200-7-Q1 or 2007-01 would be > qualified by a calendar type (in most cases ISO8601 but also possibly > USGOV-FY). This is the approach finally agreed to in SDMX-HD, for > example though I haven't seen how the IMR has implemented this. We > could also be less grand and just call the attribute an offset rather > than a calendar type, but there may be some requirements which go > beyond a simple 3 month offset. US week numbers for example :-) > > Cheers > Bob > > On 23 February 2011 06:11, Jason Pickering <[email protected]> > wrote: > > Hi there. I was wondering if it would be possible to implement the fiscal > > year period type? This meay have come up before, but it seems we may need > it > > soon. > > > > FY 2010 runs from October 1st 2009 through September 30th 2010. > > FY 2011 is from October 1st 2010 through September 30th 2011. > > FY 2012 is from October 1st 2011 through September 30th 2012. > > > > I think it would look something like this..perhaps.. > > > > private Period createPeriod( Calendar cal ) > > { > > cal.set( Calendar.YEAR, cal.get( Calendar.YEAR ) + cal.get( > > Calendar.MONTH ) % 10 ); > > cal.set( Calendar.MONTH, Calendar.OCTOBER ); > > cal.set( Calendar.DATE, 1 ); > > > > Date startDate = cal.getTime(); > > > > cal.add( Calendar.YEAR, 1 ); > > cal.set( Calendar.DAY_OF_YEAR, cal.get( Calendar.DAY_OF_YEAR ) - > 1 > > ); > > > > return new Period( this, startDate, cal.getTime() ); > > } > > > > What I am not sure about is all the rest of the methods which need to be > in > > the API, as well as the aggregation engine. Data will be entered in our > case > > quarterly, but needs to be aggregated to fiscal years. > > > > Regards. > > Jason > > > > > > -- > > Jason P. Pickering > > email: [email protected] > > tel:+260974901293 > > > > _______________________________________________ > > Mailing list: https://launchpad.net/~dhis2-devs > > Post to : [email protected] > > Unsubscribe : https://launchpad.net/~dhis2-devs > > More help : https://help.launchpad.net/ListHelp > > > > > > _______________________________________________ > Mailing list: https://launchpad.net/~dhis2-devs > Post to : [email protected] > Unsubscribe : https://launchpad.net/~dhis2-devs > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : [email protected] Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
