On the page, repeatedly, with different datasets and different dates, while the Download log performed correctly.  I did not try the csv link - why would I when the filter was clearly not working?

Inconsistency on G5 is one of the few things we can rely on, like death and taxes, so it comes as a surprise that right now it it doing exactly the same as it did on Saturday.

The most worrying thing, of course, though this time *not* surprising, is that after I reported my problem you find even more problems lurking unnoticed.  All this coming close to a year and a half after G5 went live.  Why should anyone have any confidence in *anything* that we see here, as it is obvious that the elementary testing that should have been done 2y or so ago and for every relevant change in coding has not happened.

Murdo

Thanks, Matt.  I have just checked the situation with the Badger and FLLP sets.  It still fails, and the .csv download is also not filtered.

I am not preparted to make you an administrator.  If this turns out to be a problem only with HBRG sets, I will eat my boots on live TV.  The data have passed your own validation checks (speak to Dario, who dealt with our updates in the past couple of weeks), so if there is a problem related to data, you have just uncovered another problem in your system.

What I fail to comprehend is why two apparently identical interfaces (Download log and View/REST) which should be using the same filtering routine should give such different results.

In passing, the delay in replying is down to a failure of the Forum system to notify me of your response, despite the fact I am flagged as subscribing, and not for the first time recently.  I also had no notification of responses to the item posted by Chris Johnson the other day, nor of yesterday's posts in the UKSI forum.  So yet another malfunction for someone to investigate.

Murdo

I have just had to resort to downloading the .csv files for our datasets.  Naively, I assumed that I would be able to filter for the past 12 months myself, Excel being well endowed with functions and commands that are designed to make life easy for users.

Then, of course, reality intruded.  I find that the download date in the .csv is of the format 'Wed Feb 18 2015 13:41:03 (GMT)'.  That, of course makes any use of the Excel date-manipulation functions to covert text to date utterly useless.

Yes, I could spend an hour or so writing (and *testing*) my own formulae to extract the relevant bits of the string, and format a useable date value, and then filter the rows, but I do have other rather more important calls on my time, and once again I ask myself if anyone involved in designing the G5 interface gave any thought at all to how real people in the real world would want to use it effectively and efficiently.

Keep a dog and bark yourself? Someone obviously thinks that is a sensible option.

M.

Thanks, Matt, but I have spent so long on this already that I am reporting the unfiltered views.

M.

You have (or someone has) apparently helped inadvertently, Paul.  I have just tried the View/REST filter exactly as I did last week, and the filter now works as one would expect.  That is, when I ask for results since 1 April 2014, that is exactly what I get.

I do not believe that this problem is (was) specific to the HBRG sets, and the fact that the problem seems to have been fixed without admin privileges supports that view.  The filter on dates should not have anything to do with the contents of our datasets.  Only two fields would seem to be relevant - the dataset key and the date of access.  Neither of these has anything to do with files that I can access as administrator - they are in your log.

Murdo

PS - once again, I got no notification of Paul's post.