dhis2-devs team mailing list archive

[Lars Helge Øverland <larshelge@xxxxxxxxx>]

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 <bobjolliffe@xxxxxxxxx> 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 <jason.p.pickering@xxxxxxxxx>
> 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: jason.p.pickering@xxxxxxxxx
> > tel:+260974901293
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~dhis2-devs
> > Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~dhis2-devs
> > More help   : https://help.launchpad.net/ListHelp
> >
> >
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs
> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help   : https://help.launchpad.net/ListHelp
>