Hub API does not return timestamps with timezone info

[newgene]

The hub creates timestamps (e.g. various started_at values) with proper timezone info, when it writes to MongoDB, it's stored as ISODate which is in UTC. Hub API currently returns these timestamps as UTC but without timezone. This results in some time shift when displayed in Studio web app (using vue-moment for rendering).

[zcqian]

Time stamps don’t have time zone. The convention is that it’s usually the time elapsed since Jan 1 1970 UTC. Variations do exist but on typical UNIX/POSIX systems it’s that way.

We should fix the way front end deals with the time stamp.

[newgene]

This is not specific to an individual hub API, should be related to how we store these datetime values and/or how to retrieve/encode them in JSON from the hub API.

You can see the issue in this example: first create a new build in Studio app, you will see the studio app display it as "Build time: started in 7 hours" (something like that), which clearly has a 7hr offset for our timezone.

From the hub, this started_at timestamp has the timezone info:

https://github.com/biothings/biothings.api/blob/8e0416b95661b8539d66d4978e859aef005b7ae5/biothings/hub/databuild/builder.py#L321

It is then stored in MongoDB as ISODate, e.g.:

"started_at" : ISODate("2021-07-14T00:37:30.034Z"),

Returned from hub API as:

started_at: "2021-07-14T00:37:26.256000"

which loses the timezone info.

The timezone info can be lost either when this value was read from MongoDB or when hub API serializes this value.

We may not want to just ask UI to assume UTC timezone when timezone is missing, better to figure out to carry the timezone all the way to the UI.

The rendering of the build time in Studio app is here using vue-moment package:

https://github.com/biothings/biothings.api/blob/621887f04aae13c3a775aea9aa7daacb92ae7ef0/biothings/hub/webapp/src/Build.vue#L47

This issue is not just for the build time, also for other similar timestamps in dump, upload steps.

[zcqian]

Huh, never knew we were passing date time information as strings. To be honest I think we shouldn't be doing that, I think real timestamps (seconds or milliseconds since epoch) are less ambiguous.

If we follow the recommendations from this piece: https://stackoverflow.com/a/15952652 and do encode it as a string, the date time should always be in UTC (see this and this piece of documentation for JavaScript). Therefore while we need to fix the hub API, the frontend should also make the assumption that time zone is UTC.

[newgene]

close this one as it has been fixed quite a while ago.