# Date field data - non-ISO values e.g. "Unknown" / blank

**URL:** <http://forum.companieshouse.gov.uk/t/date-field-data-non-iso-values-e-g-unknown-blank/888>\
**Category:** Uncategorized\
**Created:** [December 14, 2016, 10:15am UTC](http://forum.companieshouse.gov.uk/t/date-field-data-non-iso-values-e-g-unknown-blank/888 "2016-12-14T10:15:57Z")\
**Posts on this page:** 18\
**Page:** 1

<div class="post-metadata">

**Author:** ![voracityemail](http://forum.companieshouse.gov.uk/letter_avatar_proxy/v4/letter/v/b77776/32.png) [@voracityemail](http://forum.companieshouse.gov.uk/u/voracityemail)\
**Post date:** [December 14, 2016, 10:15am UTC](http://forum.companieshouse.gov.uk/t/date-field-data-non-iso-values-e-g-unknown-blank/888/1 "2016-12-14T10:15:57Z")

</div>

Date fields blank, null or “Unknown”. Examples:

- 00365818 - companies search has _"date\_of\_cessation_": “ **Unknown** ”, company profile just doesn’t have this field. Company “status”: “dissolved”.
- NF002764 - companies search: “_date\_of\_cessation_”: “ **Unknown** ”, company profile doesn’t have this field. “company\_status”: “converted-closed”
- SZ000001 - companies search has “_date\_of\_creation_”: **null** , company profile has “_date\_of\_creation_”: “”. Company “status”: “active”.

Related issues have been noted before - IIRC we’ve also found epoch-format values in date fields (sorry, no example recorded):

> [@Non standardised date formats](http://forum.aws.chdev.org/t/non-standardised-date-formats/588):
>
> Hi, We’ve recently been noticing some irregularities with the format of dates with the filing-history end point. Sometimes we’re receiving Epoch format and sometimes we’re receiving a string formatted YYYY-MM-DD. An example is company 06866765, for which we see mixed formats: { “type”: “CERTNM”, “description”: “certificate-change-of-name-company”, “resolutions”: [{ “category”: “change-of-name”, “date”: 1405327611000, “description”: “resolution-change-of-name”, “description\_values”: { …

P.S. dates within “description\_values”: { “description”} (“legacy” fields) in filing history - presumably these won’t be marked up and will stay as plain data? Example from company 00229606 (some fields removed for clarity):  
{  
“description”: “legacy”,  
“links”:  
{  
“self”: “/company/00229606/filing-history/MDAxMjU4NjA0NGFkaXF6a2N4”  
},  
“description\_values”:  
{  
“description”: “Return made up to 25/07/05; full list of members”  
},  
“type”: “363s”,  
“date”: “2005-08-18”,  
“category”: “annual-return”,  
“transaction\_id”: “MDAxMjU4NjA0NGFkaXF6a2N4”  
}

---

<div class="post-metadata">

**Author:** ![frank](http://forum.companieshouse.gov.uk/letter_avatar_proxy/v4/letter/f/3d9bf3/32.png) [@frank](http://forum.companieshouse.gov.uk/u/frank)\
**Post date:** [December 14, 2016, 11:45am UTC](http://forum.companieshouse.gov.uk/t/date-field-data-non-iso-values-e-g-unknown-blank/888/2 "2016-12-14T11:45:40Z")

</div>

As an external consumer and refiner of Companies House data I am far from clear what you are trying to achieve and, more importantly, what you expect their systems to supply you with.

Taking 00365818 as the example this company was dissolved; the last accounts, which we of DORMANT type covering the accounting period to 2 April 1994. Interpretation of the data suggests it was dissolved in the succeeding 2 or 3 years by Compulsory Strike-off so it effectively moved to the Companies Closed Register a good 20 years ago.

If you were permitted to use our system you would not, as a user, be allowed to see the closed archive; I think that we are very fortunate to be able to see anything at all like this on the open, ACTIVE, public system.

Frank Murphy, CEO, StatBooks Ltd

---

<div class="post-metadata">

**Author:** ![ash](http://forum.companieshouse.gov.uk/letter_avatar_proxy/v4/letter/a/f19dbf/32.png) [@ash](http://forum.companieshouse.gov.uk/u/ash)\
**Post date:** [December 14, 2016, 1:54pm UTC](http://forum.companieshouse.gov.uk/t/date-field-data-non-iso-values-e-g-unknown-blank/888/3 "2016-12-14T13:54:34Z")

</div>

This is an issue with the quality and consistancy of data on a beta service that we’re testing. What someone is trying to achieve by reporting this issue seems fairly self evident. Given that Companies House also consumes and refines their own API through the beta search site, raising awareness of these issues benefits them as well.

Taking 00365818 as an example…

The fact that this company has an Unknown date\_of\_cessation in the company search results means that beta search site doesn’t know how to deal with it and they end up with this:

> **[Search Companies House](https://find-and-update.company-information.service.gov.uk/search?q=00365818)**

_BOWMER & KIRKLAND (PLANT) LIMITED_  
_00365818 - Dissolved on_  
_Stratton House, Piccadilly, London, W1X 6AS_

Which is not ideal in terms of presentation and something I’d be surprised if they didn’t want to fix at some point.

It’s also something I wasn’t aware could happen, and potentially would have never been aware of if I hadn’t read this post, so I can go and check how the systems that consume and refine Companies House data, that I’m responsible for, deal with this.

So thanks for posting it!

---

<div class="post-metadata">

**Author:** ![frank](http://forum.companieshouse.gov.uk/letter_avatar_proxy/v4/letter/f/3d9bf3/32.png) [@frank](http://forum.companieshouse.gov.uk/u/frank)\
**Post date:** [December 14, 2016, 2:50pm UTC](http://forum.companieshouse.gov.uk/t/date-field-data-non-iso-values-e-g-unknown-blank/888/4 "2016-12-14T14:50:56Z")

</div>

The point I was trying to make here was are events, and related data, from 20 years ago for a dissolved company actually relevant to anyone now.

I did not have an issue with the question per se but would have liked, and would still like, to know the rationale(s) that led to it!

---

<div class="post-metadata">

**Author:** ![ash](http://forum.companieshouse.gov.uk/letter_avatar_proxy/v4/letter/a/f19dbf/32.png) [@ash](http://forum.companieshouse.gov.uk/u/ash)\
**Post date:** [December 14, 2016, 3:34pm UTC](http://forum.companieshouse.gov.uk/t/date-field-data-non-iso-values-e-g-unknown-blank/888/5 "2016-12-14T15:34:59Z")

</div>

This could be relevant in some sectors (legal being the one we’re most likely to deal with, but there may be others), but from my (developer) perspective it’s not about relevancy and availability, but the ability to create an interface that returns…

_00365818 - Dissolution date unknown_

instead of

_00365818 - Dissolved on_

or even just crashing, when it encounters something other than the expected data. In the documentation date\_of\_cessation/creation are both listed as optional date fields in search and profile. The fact that these fields can also be **null** or a non-date string **Unknown** are issues whether or not the data itself is relevant.

---

<div class="post-metadata">

**Author:** ![frank](http://forum.companieshouse.gov.uk/letter_avatar_proxy/v4/letter/f/3d9bf3/32.png) [@frank](http://forum.companieshouse.gov.uk/u/frank)\
**Post date:** [December 14, 2016, 5:17pm UTC](http://forum.companieshouse.gov.uk/t/date-field-data-non-iso-values-e-g-unknown-blank/888/6 "2016-12-14T17:17:00Z")

</div>

OK - I can see the potential relevance to the legal sector but probably in a more recent past than twenty years ago. I may also have to change my views on relevance as well; some around me would say that was a good thing!

I totally agree with you that if the data is available then the interface should actually return that data and not **unknown** or **null**. Perhaps the issue here will prove to be actually availability within what was loaded.

I even more totally agree that the interface must not crash on encountering the unexpected.

We are on the same side really.

It will be interesting to see a response on this topic from the Companies House team!

---

<div class="post-metadata">

**Author:** ![voracityemail](http://forum.companieshouse.gov.uk/letter_avatar_proxy/v4/letter/v/b77776/32.png) [@voracityemail](http://forum.companieshouse.gov.uk/u/voracityemail)\
**Post date:** [December 15, 2016, 5:41pm UTC](http://forum.companieshouse.gov.uk/t/date-field-data-non-iso-values-e-g-unknown-blank/888/7 "2016-12-15T17:41:09Z")

</div>

Thanks for replies - my perspective was as a developer wanting to share what I’d found as much as hoping for definitive answers. I’ve learned quite a bit from reading around here. I expect changes here and appreciate that such a large and long-lived dataset will have exceptions. It’s because CH _do_ seem to be helpful and responsive I’m asking whether there are “known unknowns”.

By-the-by I do work for the legal side so “old data” can sometimes be relevant although the particular data is by way of example.

---

<div class="post-metadata">

**Author:** ![voracityemail](http://forum.companieshouse.gov.uk/letter_avatar_proxy/v4/letter/v/b77776/32.png) [@voracityemail](http://forum.companieshouse.gov.uk/u/voracityemail)\
**Post date:** [December 15, 2016, 8:11pm UTC](http://forum.companieshouse.gov.uk/t/date-field-data-non-iso-values-e-g-unknown-blank/888/8 "2016-12-15T20:11:11Z")

</div>

…for a more recent date example, this time in Unix epoch (milliseconds), filing history, company #03888792, again some fields removed:  
{  
“associated\_filings”: [  
{  
“action\_date”: **1447113600000** ,  
“category”: “capital”,  
“date”: “2015-11-10”,  
“description”: “statement-of-capital”,  
“description\_values”:  
{  
…  
“date”: “2015-11-10”  
},  
“original\_description”: “10/11/15 Statement of Capital;GBP 1339546478.75”,  
“type”: “SH01”  
}],  
“type”: “AR01”,  
“description”: “annual-return-company-with-made-up-date-no-member-list”,  
“date”: “2015-11-10”,  
“category”: “annual-return”,  
“barcode”: “A4IG6XHU”,  
“transaction\_id”: “MzEzNDg4NjczOGFkaXF6a2N4”  
…  
}

Yes, here we get _date_ correctly in _description\_values_. But does this represent a bug, or will _dates_ be “mostly ISO format, occasionally ‘Unknown’ or null, and rarely epoch”?

Anyway, over to Companies House team.

---

<div class="post-metadata">

**Author:** ![frank](http://forum.companieshouse.gov.uk/letter_avatar_proxy/v4/letter/f/3d9bf3/32.png) [@frank](http://forum.companieshouse.gov.uk/u/frank)\
**Post date:** [December 16, 2016, 11:38am UTC](http://forum.companieshouse.gov.uk/t/date-field-data-non-iso-values-e-g-unknown-blank/888/9 "2016-12-16T11:38:47Z")

</div>

This is a good piece of drain cover lifting.

It will be most interesting to know what else you find and to hear from the Companies House team.

Keep on lifting those covers!!

---

<div class="post-metadata">

**Author:** ![phillips\_chris](http://forum.companieshouse.gov.uk/letter_avatar_proxy/v4/letter/p/48db29/32.png) [@phillips\_chris](http://forum.companieshouse.gov.uk/u/phillips_chris)\
**Post date:** [February 17, 2017, 8:40am UTC](http://forum.companieshouse.gov.uk/t/date-field-data-non-iso-values-e-g-unknown-blank/888/10 "2017-02-17T08:40:53Z")

</div>

I have just come across this problem when searching for ‘Axa’. Some of the records returned have date\_of\_cessation set to ‘Unknown’.  
Since the date format used by Companies House is of the form “2016-12-13” and we want to display it as ‘13-Dec-2016’ this makes it very difficult for us to do the conversion. I’m not sure that even checking the first character is numeric would do the trick since one can apparently get dates in the format ‘1405327611000’.  
Would checking that the first two characters are ‘18’, ‘19’ or’20’ do it? How far back do Companies House records go?

---

<div class="post-metadata">

**Author:** ![voracityemail](http://forum.companieshouse.gov.uk/letter_avatar_proxy/v4/letter/v/b77776/32.png) [@voracityemail](http://forum.companieshouse.gov.uk/u/voracityemail)\
**Post date:** [February 17, 2017, 12:33pm UTC](http://forum.companieshouse.gov.uk/t/date-field-data-non-iso-values-e-g-unknown-blank/888/11 "2017-02-17T12:33:28Z")

</div>

CH seems to have gone a bit quiet on responding here on the documentation front or for data issues. I suspect this will be the case 'till the Swagger-compatible docs are available. However - they clearly do take note. And their documentation is quietly being updated over time.

As noted, I’ve found it’s wise to trap the following:

- Values of “unknown” and “null” for non-text fields.
- Values of “null” for objects e.g. address / registered\_office\_address
- Integers possibly starting with 0 e.g. month and year in  
date\_of\_birth.
- Dates as YYYY-MM-DD or Epoch format (and if you want to poke inside  
fields e.g. filing history good old DD/MM/YY put in by humans).
- Undocumented constant values in lookup fields.
- Unusual-looking markdown in e.g. filing history description constants “[\< link text \>]” for links.
- UK company registration numbers missing leading / internal zeros (for corporate officers / PSCs).

The company reg. number mentioned last may be missing entirely. This is a nuisance but we’re probably stuck with it - see [Officer List return company number for corporates?](http://forum.aws.chdev.org/t/officer-list-return-company-number-for-corporates/976). So to find company data on such officers we’re back to hoping given names match company names - see [Comapny Name matching question](http://forum.aws.chdev.org/t/comapny-name-matching-question/709)

I think the policy is of “just recording what we get on the form”. (In a perfect world some of these might be validated / corrected where it’s “obvious” what is meant…some things e.g. dates, filings get put into formats…)

---

<div class="post-metadata">

**Author:** ![voracityemail](http://forum.companieshouse.gov.uk/letter_avatar_proxy/v4/letter/v/b77776/32.png) [@voracityemail](http://forum.companieshouse.gov.uk/u/voracityemail)\
**Post date:** [February 17, 2017, 12:44pm UTC](http://forum.companieshouse.gov.uk/t/date-field-data-non-iso-values-e-g-unknown-blank/888/12 "2017-02-17T12:44:00Z")

</div>

I wonder how far back the records go also. There are obviously old companies around. I’ve seen:

SC012574 - Incorporated on 22 February 1923  
00289141 - Incorporated on 14 June 1934

I’m not sure the [Shore Porters](https://en.wikipedia.org/wiki/Shore_Porters_Society) falls under CH remit…

---

<div class="post-metadata">

**Author:** ![ash](http://forum.companieshouse.gov.uk/letter_avatar_proxy/v4/letter/a/f19dbf/32.png) [@ash](http://forum.companieshouse.gov.uk/u/ash)\
**Post date:** [February 20, 2017, 9:59am UTC](http://forum.companieshouse.gov.uk/t/date-field-data-non-iso-values-e-g-unknown-blank/888/13 "2017-02-20T09:59:07Z")

</div>

I think the oldest is Marine and General [https://beta.companieshouse.gov.uk/company/00000006](https://beta.companieshouse.gov.uk/company/00000006) I only know that off the top of my head because it gets used in examples a lot!

---

<div class="post-metadata">

**Author:** ![voracityemail](http://forum.companieshouse.gov.uk/letter_avatar_proxy/v4/letter/v/b77776/32.png) [@voracityemail](http://forum.companieshouse.gov.uk/u/voracityemail)\
**Post date:** [February 23, 2017, 12:08pm UTC](http://forum.companieshouse.gov.uk/t/date-field-data-non-iso-values-e-g-unknown-blank/888/14 "2017-02-23T12:08:52Z")

</div>

Where (presumably) underlying data fields are missing / unknown this may affect several fields. An example from Companies search: NF003350 (admittedly this looks like a rather odd old entry).  
“date\_of\_cessation” is “Unknown” and the description is incomplete also:

```
{
  "date_of_cessation": "Unknown",
  "company_number": "NF003350",
  "description": "NF003350 - Closed on " ...
}
```

---

<div class="post-metadata">

**Author:** ![ash](http://forum.companieshouse.gov.uk/letter_avatar_proxy/v4/letter/a/f19dbf/32.png) [@ash](http://forum.companieshouse.gov.uk/u/ash)\
**Post date:** [February 23, 2017, 2:57pm UTC](http://forum.companieshouse.gov.uk/t/date-field-data-non-iso-values-e-g-unknown-blank/888/15 "2017-02-23T14:57:26Z")

</div>

By chance, I encountered another “Closed on …” company earlier today, also an NF company: NF002699

There’s an enumeration for a status of “closed” rather than “closed-on”, which does not require a date, which suggests to me that when the date is unknown it should have been given that status instead.

I’ve been a little frustrated with this stuff today. As we don’t have access to the underlying data or the logic that CH employs to consume the API on the Beta search site there ends up being a lot of trial and error and guesswork involved. Made even more frustrating when we don’t get a response to a lot of documentation/data issues raised here. Please keep posting them though, they’re helpful to me at least!

---

<div class="post-metadata">

**Author:** ![voracityemail](http://forum.companieshouse.gov.uk/letter_avatar_proxy/v4/letter/v/b77776/32.png) [@voracityemail](http://forum.companieshouse.gov.uk/u/voracityemail)\
**Post date:** [February 27, 2017, 9:11pm UTC](http://forum.companieshouse.gov.uk/t/date-field-data-non-iso-values-e-g-unknown-blank/888/16 "2017-02-27T21:11:53Z")

</div>

Yup, definitely sounds like a bug.

It’s been a slightly odd experience working with this system - lack of documentation is annoying but then people have been very helpful (sometimes even CH although not with a direct response).

Roundabouts and swings, and maybe sometime we’ll have it all in Swagger… Good luck!

---

<div class="post-metadata">

**Author:** ![voracityemail](http://forum.companieshouse.gov.uk/letter_avatar_proxy/v4/letter/v/b77776/32.png) [@voracityemail](http://forum.companieshouse.gov.uk/u/voracityemail)\
**Post date:** [March 7, 2017, 12:57pm UTC](http://forum.companieshouse.gov.uk/t/date-field-data-non-iso-values-e-g-unknown-blank/888/17 "2017-03-07T12:57:03Z")

</div>

Late response but are any of those with `date_of_cessation` set to ‘`unknown`’ AC / IC / BR companies? CH doesn’t hold info on those. However from data seen I’d then not expect _any_ `date_of_cessation` field to be returned…

---

<div class="post-metadata">

**Author:** ![voracityemail](http://forum.companieshouse.gov.uk/letter_avatar_proxy/v4/letter/v/b77776/32.png) [@voracityemail](http://forum.companieshouse.gov.uk/u/voracityemail)\
**Post date:** [March 7, 2017, 1:30pm UTC](http://forum.companieshouse.gov.uk/t/date-field-data-non-iso-values-e-g-unknown-blank/888/18 "2017-03-07T13:30:19Z")

</div>

FYI I’ve noted the issues with missing dates in another post on the search resources:

> [@Search resource documentation incorrect / gotchas](http://forum.aws.chdev.org/t/search-resource-documentation-incorrect-gotchas/1017):
>
> Minor issue but for reference the search resource documentation (all four types) is incorrect: field “description\_identifier” is listed as ["integer"] …but (as it states further down) these return string constants which appear in the search\_descriptions\_raw.yaml file. There are separate sets of constants for company, officer and disqualified officer searches and these are given in search\_descriptions\_raw.yaml but since the general search can return results of any of these types you’ll need …
