Specifying time in release date.

[isadon]

Any thoughts on adding the time in the release date section. So something like 2020-10-03 19:20. 19:20 is in the hh:mm format in UTC.

PS: I don't know if this project has specified this but the date already being used should also be UTC. I can specify my release date to be 2020-12-15 EST but in some other timezone it might be 2020-12-16 already.

[k-mack]

You could follow ISO 8601 to format the date and time of the release. For example, instead of 2020-12-16 you could write 2020-12-16T13:59:23+00:00 or 2020-12-16T13:59:23Z to include the time and time zone.

[olivierlacan]

How is the full machine-oriented ISO datetime relevant to a release date? Any date parser worth its salt can parse YYYY-MM-DD if that's necessary. As I've pointed out at length throughout this project, changelogs are for humans, machine readability is a distant secondary concern.

Moreover, does 2020-12-16T13:59:23+00:00 look readable for a human to you when browsing through a list of 10, 20 or 30 releases. It's mostly irrelevant noise because in the vast majority of cases, there will not be more than one release in a given day. So here, the lack of granularity in what we expose as top-level data for a release is a feature, not a bug.

To answer @donileo I don't think it's necessary for this project to recommend a timezone. The reason is similar to why I don't think hours are relevant. It's a release date, not a release time. Now I'm sure there might be projects out there that release so often as to need to differentiate multiple releases on the same day. At which point I'd say, well, add a 24-hour time as you've suggested: 2020-10-03 19:20.

[isadon]

@olivierlacan The real issue for me is the "reference" of time. Once you put <date, time, or date+time> into anything, a file, a human friendly changelog etc its meaningless unless it's specified what timezone it references.

For my use cases I'm trying to use CHANGELOG.md as the release notes for an app. A "machine" will parse these notes (maybe even release dates) for submitting to an App store for example. The issue isn't the machine parsing the notes its that time is useless unless you mention whats your point of reference. A person across the world will look at the release notes dates from their point of reference (Timezone) and will misinterpret the dates unless its specified its UTC or whatever TZ it is.

I understand the motivation in keeping the changelog entries human friendly and I think that can be done. Only change I'm requesting at this point is for the spec to state that the dates/times have to be in UTC (even if not marked as UTC in the log entries).

As a nice-to-have, it'd be cool if an optional format for the dates that included time was also mentioned in the spec.

[Nixinova]

unless it's specified what timezone it references

Seems like a simple fix, specify (e.g.) "times in EST" at the start of the document.

I don't think UTC should be mandated; "assume UTC unless specified otherwise" might be a good idea, however.

[isadon]

unless it's specified what timezone it references

Seems like a simple fix, specify (e.g.) "times in EST" at the start of the document.

I don't think UTC should be mandated; "assume UTC unless specified otherwise" might be a good idea, however.

The "times in EST" or mentioning what the times are pegged to up top is a valid solution but it needs to be stated somewhere; either in the individual datetime strings (by way of including the timezone) or up top somewhere.