SPRINT: Update observations files to use dateTime

[neill-b]

Description

For some time the previous method of specifying the date-time of observations has been deprecated. I have applied a simple code to convert (almost) all the observation files to use dateTime. To do this I have removed MetaData/time, MetaData/datetime and date_time from the files, and replaced these with MetaData/dateTime with a reference date set using the global attribute (if set, otherwise defaulting to 1970-01-01).

At the same time I have removed the global attributes "history" and "NCO", since they are never required and "history" has been known to cause issues. Mike requested that I use the MetaData/datetime in preference to MetaData/time. To achieve this I have sorted the variable, so some of the variables are in a different order in the file to previously.

There are three files which I have been unable to update: QFEtoQNH_obs_20210521T1200Z.nc4 PStar_obs_20210521T1200Z_noflag.nc4 PStar_obs_20210521T1200Z.nc4

Any minor modification to these files appears to break the ctests, so I have decided to leave them alone.

I have run all the ufo ctests, and these changes to do alter the set of tests which pass/fail (compared to Greg's branch).

Issue(s) addressed

None

Acceptance Criteria (Definition of Done)

Files merged.

Dependencies

None

Impact

None

[mikecooke77]

@neill-b how easy is it to re-run these changes. I'm trying to work out the best order to make changes with #248 , #263 , #258

[gthompsnJCSDA]

@neill-b While I like the idea of what you did with this, the problem is that it comes in after I already hand-edited nearly 130 files using NCDUMP then rebuilt the files using NCGEN after I edited away the deprecated elements of nvars and nrecs and the group VarMetaData. So if this were to merge into our primary sprint branch - all my manual edits would be gone and the deprecated elements would return.

Therefore, how simple would it be for you to wait until about 4 other PRs get merged into the primary sprint branch, then you freshly pull/sync to your disk the entire set of files, then re-run your dateTime fixaroo on the freshest set of files possible?

If this program you wrote is designed to update the string-formatted datetime to newer dateTime then it should work fine for the Geoval files as well. But if it does variable name substitutions, then it would not be good.

Could you switch this to DRAFT mode until we straighten out things with other PRs then update your files again afterwards?

[neill-b]

@gthompsnJCSDA - there was a fair bit of fiddling around, as there were some files which needed some hand-editing. And, given that ufo-data branches can't be merged I'll just have to start again. Let me know when I can have a clear run at making this change. The code could be adapted to work for geovals too, but I haven't tested that yet.

[mikecooke77]

@neill-b are you happy for this to be closed?

[neill-b]

Close this PR, as the work will need to start again from a new base.

[neill-b]

But, please nobody delete the branch...