Relationship between `activity-status` and `activity-date`s

I have some basic questions, after reading @anjesh’s excellent blog.

  1. Should an activity in implementation (an activity-status of 2) be allowed an actual end date?
  2. Should an activity in pipeline/identification (an activity-status of 1) be allowed an actual start date, or actual end date?

According to the standard, actual dates must be in the past. But the above rules aren’t currently included in the standard ruleset, or anywhere in the reference documentation. Should they be?

Asking this now because the ruleset is currently being worked on, and because the new IATI Validator is around the corner (congratulations, @rolfkleef!) which will do ruleset testing.


Not the answer you are looking for, but if we are going to have rulesets, then I am even less clear that that we need an ‘activity-status’ field given that it can be imputed from the start/end dates and the current date.

I think an issue is that the process/standard was designed for publishers who regularly re-publish and so the status gets updated when the start-date is passed, but as in the Belgian example (I guess) there are lots of publishers doing it irregularly - removing and instead imputing the activity-status would make it a lot easier for them. Of course it doesn’t solve the issue of a project that doesn’t actually start by the start date, but nor does the current situation.

RE the actual questions, my take is:

  1. Yes, you want to be able to predict when the project will end - and I often end up using it to estimate the upcoming disbursements ((activity value - disbursements to date) / remaining years) where the forward spending data is not provided.
  2. Yes, because it is often helpful to know when a project is due to be active / be spending.

As above, if the ruleset enforced forward spending data, then this would change - you wouldn’t need project dates, but could impute them from the spending i.e. date of first transaction = start date, date of last projected transation = end date.

I think my thinking here, is that in the absence of a ruleset that works in all cases, or is enforced, then the more data the better to try and figure out what is happening, despite the business-logic flaws that this involves.

1 Like


In my humble opinion I don’t think it makes sense for something that hasn’t finished to have an actual end date nor a project that hasn’t started to have an actual start date. Planned yes. Actual no.

Having the standard impute anything is a tad risky in my opinion. What happens when a project starts or ends on the date of publishing and one isn’t in the same time-zone as IATI (GMT I believe)? The system logic may not know what to do or give a result the publisher isn’t looking for.

Hope that helps.

1 Like

@Michelle_IOM thanks - this points out that my suggestions of actual dates being important should actually refer to planned dates. Does this mean that you think the ruleset should now reject all activities with actual dates set in the future - @andy can you tell if there are there a lot of these?

RE Imputing things - the technical answer to your example is for the date to also reference the timezone that it applies to (is this a feature that we have in the standard?).

I often think that exact dates for activities are fairly meaningless (and aside from those for calculating loan disbursements would argue for just MM/YYYY) - if the actual start date was the 15th of May, but that is a Saturday and so work started until the 17th of May in reality no-one bats an eyelid - so why does IATI need to be so precise? Most projects have an 30th/31st of the month end date - again, likely to bear little relation to the actual end of activities, in which case we shouldn’t really worry about making dates seem more precise than they are in reality. Otherwise we should start putting in separate dates for the date a transaction was sent, and the date it arrived etc. It is also not clear what part of an activity the dates refer to - i.e. if the donor started thinking about a project in Jan, but its first expenditure was in June, the start date is already pretty useless to many users.

@matmaxgeds Hmm… Perhaps… But also: removing activity-status would happen at a major upgrade, so that’s a v3.0.0 discussion! Can we park that one? :slight_smile:

Great – thanks @Michelle_IOM!

It’s not a feature of the standard, no.

Michelle raises a good point here, though. Perhaps some grace period would be good, to allow for these sorts of edge cases?

Yes, every MUST in the standard that cannot be validated by the schema MUST have a rule in gthe standard ruleset.

That works for “Implementation” but not for all status codes? (And we’re not in the business of re-egineering the standard at the moment, right?)

I agree

Given that some exact dates may have meaning the original thinking was that using xsd:date (yyyy-mm-dd)** for all dates - and using the first and last days of the month for non-specific dates - was a pragmatic solution.

** the attibute label @iso-date is misleading as yyyy-mm is valid for ISO 8601 but not for xsd:date. (I think I’m correct on this.) But we’re hardly going to re-engineer the standard now, right?

I don’t think we need a grace period for how the validator approaches its work. (It has to be loyal to the standard alone.) The DataStore is a different matter: it should in my opinion ingest future actual dates (or correct them to planned?). No doubt this will arise in the forthcoming consultation on such issues.

1 Like

The rules mentioned above are not MUSTs in the standard (unless I am mistaken?) I don’t think they’re included anywhere in the reference documentation. Should they be?

@bill_anderson Yes – exactly. None of those rules are about the relationship between activity-date and activity-status.

Ah, sorry. Missed that point. Yes, we should have related rules. NB. @amys @petyakangalova

1 Like


That’s what I assumed, glad you confirmed.

Absolutely not! The first transaction is not necessarily the start date, and more importantly the last projected transaction is very/most often not the end date. All kinds of things happen during the course of a project implementation that can require frontloading or delaying transactions.

1 Like

Completely understood, but then we have to be clear that the dates associated with activities certainly don’t have a financial meaning - but what meaning do they have? The standard says that “Start dates may reflect either the commencement of funding, planning or physical activity. End dates should, wherever possible, reflect the ending of physical activity.” It could be very different for different donors and different projects - which starts to make it a bit useless if in some cases it means that a team is on the ground, and in other cases it might mean it has been allocated funds internally to the donor but you might not see activity for months? I guess I feel that the ruleset should enforce that the dates need to say which if these things (planning, funding, activity) they refer to in order to be more useful.