Serving data from the past

[Bost]

First of all: Thank you sooo much for this API!!!

Could you please also serve the data from the past so we can verify our own data, make prediction graphs etc.? E.g. something like https://corona-api.herokuapp.com/<unix-timestamp> returns the data with that unix-timestamp.

Oh, BTW you may also put note in the README.md about the ts, e.g. that your data comes with a unix-timestamp "ts":1581313691.605966

Thank you in advance.

Edit: I just found out the ts timestamp is provided only by the https://corona-api.herokuapp.com/current and is missing in the other three services. Could you fix that please? Thanks.

[dawenx]

Agree with Bost's comment on the repo: really a nice job and appreciated!

A comment on the timestamp, can you add additional timestamp in another format, maybe a format the same as "Last Update" ? For example, "2020-02-09 23:33:02" in https://github.com/CSSEGISandData/2019-nCoV/blob/master/daily_case_updates/02-09-2020_2320.csv

[Bost]

A comment on the timestamp, can you add additional timestamp

Just want put some extra stress on the word add as in "accretion". Whatever additional timestamp you decide to provide do not change the existing one. IOW do not introduce any format breaking changes. Never. Thanks.

[nat236919]

@Bost @dawenx Thank you for your comments. I will look into it soon.

[dawenx]

thanks @nat236919 check out my application if you have a few minutes, i'm using JHU's data as well: https://nssac.github.io/dashboard/

[cbunicef]

I noticed that the timestamp is no longer included on the current endpoint. I would strongly suggest re-adding it, and adding it to the other endpoints as well. It's valuable because it allows us to confirm the actual date the data was collected - if your service has an error in refreshing data in the future, it would be clear by the timestamp that the data is no longer current.

Adding that it's also best practice to not make significant changes to existing endpoints, particularly removing information from them. Applications that use the "ts" object which was previously available may now be broken.

EDIT: Looking through the code I see that the timestamp is derived from the server time. You might re-add that to restore compatibility, but it would be more useful if there were a time field derived from the dataset, so that it can be confirmed what time the original data was published.

[nat236919]

@cbunicef Thank you for your comment. I have added both datetime and timestamp to the data. FYI, I am not quite sure what Time Zone they use.

[cbunicef]

Thanks @nat236919. Looks like they are using GMT for data published after Feb 1:

https://github.com/CSSEGISandData/COVID-19/tree/master/daily_case_updates

[nat236919]

@cbunicef Thank you so much

[cbunicef]

You're welcome, but I think you are looking at @dawenx's dashboard :)

[nat236919]

thanks @nat236919 check out my application if you have a few minutes, i'm using JHU's data as well: https://nssac.github.io/dashboard/

I finally got a chance to check out your dashboard; it's awesome. I was wondering if you could share your tech stack. I'm planning to generate a dashboard in the near future.

[nat236919]

You're welcome, but I think you are looking at @dawenx's dashboard :)

Sorry, that was my bad, sir. I've just realised I need to rest, lol.

[dawenx]

I talked to JHU’s developer yesterday, in their curated data, “last update” field: after 01/31 is UTC time, before 01/31 (including 01/31) was EDT. @nat236919

[nat236919]

add 'timeseries' API endpoint https://github.com/nat236919/Covid2019API/commit/5fa9788ab8055d32d68957da9ab527a428110610