18236
Reporter: rdmpage
Assignee: cgendreau
Type: Feedback
Summary: Date recorded too precise (includes timestamp)
Description: I'm sure this has come up before, but displaying the recorded date with a timestamp is misleading. The timestamp "12:00:00 AM" is clearly bogus, can this please be suppressed? There is no reason to show a value that has no meaning (and might lead users to either interpret it literally, or realise that it is spurious and hence begin to question other aspects of the data on display).
Status: Open
Created: 2016-02-16 14:58:21.522
Updated: 2016-08-20 13:33:01.289
Author: rdmpage
Created: 2016-08-20 10:53:30.047
Updated: 2016-08-20 10:53:30.047
This is still an issue, for example see recent example from DNA barcode dataset http://www.gbif.org/occurrence/1291774546
Surely this is a trivial fix? It seems ridiculous having a spurious level of precision in how we report dates...
Author: trobertson@gbif.org
Created: 2016-08-20 12:33:35.159
Updated: 2016-08-20 12:33:35.159
Yes, the issue is still "unresolved".
There is a huge workload, and not everything trivial is fixed as quickly as one likes. My guess is this may not be as trivial as one assumes - variable precision date handling with ranges across timezones isn't a trivial thing, or it'd be standard in Java etc. [JSR 310|https://jcp.org/en/jsr/detail?id=310] and [Java 8|http://www.oracle.com/technetwork/articles/java/jf14-date-time-2125367.html] goes a long way to helping though. Pull requests are of course welcome https://github.com/gbif/parsers
Author: rdmpage
Created: 2016-08-20 13:22:29.907
Updated: 2016-08-20 13:22:29.907
I understand that there's a big workload, I'm trying not to add to it...
But two things baffle me here:
1. The API call for this record returns "2009-01-13T00:00:00.000+0000" for the date, so why does the web page add an hour to that time? The HTML version contradicts the API, unless it's making a correction for viewer's time zone, which is, um, odd.
2. Why does the API return a time at all? Surely the date is "2009-01-13" with no time info at all? This is still valid ISO 8601.
Lastly, I don't speak Java so can't contribute to the code base. Maybe a task for a hackathon - fixing some of the niggling bugs ;)
Author: trobertson@gbif.org
Created: 2016-08-20 13:33:01.289
Updated: 2016-08-20 13:33:01.289
The 1hr thing is because the client of the WS is indeed GMT+1 (it sits in Copenhagen). It's odd, and that is part of the bug.
The underlying problem is that the original implementation uses Date() object which represent a moment in time (relative to the dateline). There are a group of related issues around timezones (e.g. 11:00 am in New Zealand is actually the day before in UK so needs considered handling depending on the query), what to do with dates which don't have a time component (we need to add date precision fields all the way through the stack) and how to handle collection events which span a time period which is happening more and more. It's not overly difficult but represents very invasive changes to the codebase some of which includes breaking the v1 public API. That is why it hasn't been picked up yet.
