Format date field of time series

[msbit]

Pad the start of the date field of time series to ensure the
dates are of the form:

YYYY-MM-DD

I've tested this on my repo with a per-minute action and it appears to all go through swimmingly.

[jeetiss]

This is breaking change and will destroy all projects that already use this data.

You can use https://github.com/rlindskog/covid19-graphql that support converting date format

[pomber]

Hey @msbit, thanks for the PR.

I don't think it will destroy all projects that already use this data, but there's a possibility that it may break some projects.

Since this can be done on the client, any reason you prefer to do it in the GH action?

[msbit]

@pomber

Since this can be done on the client

I'm guessing that you're referring to https://github.com/rlindskog/covid19-graphql ? If so, I wasn't aware of it until seeing @jeetiss comment.

any reason you prefer to do it in the GH action?

Well, mainly so the date is in a format that is more compatible and less likely to surprise consumers.

Either way, no stress if this PR doesn't fit with this project :)

[pomber]

I'm guessing that you're referring to https://github.com/rlindskog/covid19-graphql ? If so, I wasn't aware of it until seeing @jeetiss comment.

I'm not referring to the graphql api. I mean it can be done from any consumer of the json, for example, the javascript fetching the json.

I agree that your change makes a better date format, but I should have format it like that before people started using it. Now, making a breaking change (even small like this) isn't worth it.

Thanks again!

[msbit]

@pomber

I mean it can be done from any consumer of the json

Ah okay, this might get a little philosophical!

I've always thought that if it can be, a problem should be fixed upstream. In that way, it doesn't need to be done from any of the greater-than-one consumers of the JSON, so the overall workload across all projects is reduced. As a counterpoint, you might say that some of your consumers prefer the format that you are currently outputting. To that, I'd say every choice we make as developers is opinionated, and so will never make everyone happy; the best we can achieve, where there is no clear advantage to any, is to follow the general consensus, to create the least surprise for those that use the software. In this case, I feel we are in agreement that the format I'd proposed was closer to that general consensus.

Now, having said all that:

Now, making a breaking change (even small like this) isn't worth it.

Totally understand, feel free to close this PR

:)

[saschawildgrube]

It's a bug in my eyes. Bugs need to be fixed. If you're worried about downstream effects, create two files going forward.