Display occurrence dates with appropriate level of precision

[rdmpage]

One thing which has long driven me nuts is the way GBIF handles dates for occurrences, and this has carried over into the new portal. In many places GBIF displays an absurd level of precision for dates, including minutes and seconds (often with weird offsets for time zones). I have brought this up before to no avail. I really think we need to treat dates more sensibly. A case in point, for https://demo.gbif.org/occurrence/1030986103 the event date is given as "2001-01-01T00:00:00.000+0000"

The only information we have is that this specimen was collected in the year 2001 (see the verbatim record below) and yet this gets displayed as the stroke of midnight, January 1st. Can we use the new portal as an opportunity to fix this problem so that GBIF is not seen as providing users with spuriously precise dates?

{
	"basisOfRecord": "PreservedSpecimen",
	"catalogNumber": "e60ada9a-b6bf-11e1-8c2f-acd112e444a7",
	"countryCode": "CN",
	"county": "上思县",
	"decimalLatitude": "22.0977681",
	"decimalLongitude": "107.9579794",
	"family": "Fagaceae",
	"genus": "Castanopsis",
	"id": "4979905",
	"institutionCode": "IBK",
	"kingdom": "Plantae",
	"locality": "叫安乡三料村四队",
	"occurrenceID": "4979905",
	"recordedBy": "吴世捷",
	"scientificName": "Castanopsis amabilis",
	"source": "http://www.nsii.org.cn/node/79/cvh/33/68f/4979905",
	"stateProvince": "广西",
	"year": "2001"
}

[cgendreau]

this has been discussed on this page: gbif/gbif-api#4

[MortenHofft]

Seems very reasonable. It requires API changes to do so properly. That should be the more difficult part. Once that is in place we can start fixing it on the website. In theory we could try to do it in presentation, but it seems wrong to do it in the web layer if the API claims such precision.

[MattBlissett]

This is now deployed and all datasets have been reprocessed — the long timescale partly due to this being an API change.