html_url,issue_url,id,node_id,user,created_at,updated_at,author_association,body,reactions,performed_via_github_app,issue
https://github.com/pydata/xarray/issues/6176#issuecomment-1020681788,https://api.github.com/repos/pydata/xarray/issues/6176,1020681788,IC_kwDOAMm_X8481l48,11656932,2022-01-25T00:19:49Z,2022-01-25T01:27:00Z,CONTRIBUTOR,"> @jrbourbeau is this something dask has thought about?

Thanks for the ping @Illviljan. Zero-padding dates did come up in the Dask calver discussion starting here https://github.com/dask/community/issues/100#issuecomment-704445214. In a nutshell, there was a slight preference towards using zero-padding (i.e. `2022.01.0` instead of `2022.1.0`) because the calendar nature of the version is more explicit and string sorting and full-fledged package sorting (like one would do with `packaging.version`) give the same result. 

As pointed out https://github.com/dask/community/issues/100#issuecomment-704468187 either convention is valid from a Python packaging perspective. FWIW I'm not aware of any issues that have come up from Dask using a zero-padded version number. The main thing that comes to mind is when checking out git tags for a specific release (e.g. `git checkout 2021.04.0` and `git checkout 2021.4.0` are not equivalent). That said, to my knowledge, this hasn't been an issue in practice. 

EDIT: To be clear, I'm not advocating for one convention over the other -- just providing context around Dask's decision","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1108564253