Setuptools 8 strips leading zeros in packaging for date based releases

Originally reported by: mklein0 (Bitbucket: mklein0, GitHub: mklein0)

---

I am currently date based release version numbers to manage releases. After upgrading to setuptools 8, release segments with leading zeros in them are being striped.

The following setup.py example would generate a package name of:

dated_release-20140510.003458-cp27-none-macosx_10_9_intel.whl

After setuptools 8:

dated_release-20140510.3458-cp27-none-macosx_10_9_intel.whl

Along with the following warning:

/VirtualEnv/stools/lib/python2.7/site-packages/setuptools/dist.py:289: UserWarning: The version specified requires normalization, consider using '20140510.3458' instead of '20140510.003458'.
self.metadata.version,

I believe PEP440 allows for date based version identifiers, so this is unexpected.

Code to generate packages:

from setuptools import setup, find_packages

setup(
    name='dated_release',
    version='20140510.003458',
    description='Example of a dated release  %Y%m%d.%H%M%S',
    packages=find_packages(),
    )

---

• Bitbucket: https://bitbucket.org/pypa/setuptools/issue/302

Original comment by dstufft (Bitbucket: dstufft, GitHub: dstufft):

---

This is expected behavior with PEP 440. It interprets each segment in the 20140510.003458 as an integer which means that it essentially does ".".join([str(int(x)) for x in "20140510.003458".split(".")]).

I have to admit I'm not sure what the 003458 signifies, is that HHMMSS with a 24 hour clock? I'll admit that when we wrote PEP 440 I don't think anyone considered what would happen if someone wanted to expand date based version numbers to also include 24 hour clocks. The reason for the stripping of the leading 0 is so that something like 00 is equal to 0 because that's generally how people think of those versions. I'm not sure I can think of a good way to change PEP 440 that would allow the exact version string you've picked without breaking the 00 == 0 rule. Probably the best way for you to get the effect you're trying is to either remove the . or add more . and do something like 20140510.0.34.58 or even 2014.05.10.0.34.58 or 20140510003458.

Original comment by mklein0 (Bitbucket: mklein0, GitHub: mklein0):

---

The timeformat is: %Y%m%d.%H%M%S or YearMonthDate.HourMinuteSeconds

Ok, my interpretation of the example was leading 0 is acceptable in the version identifier (due to the date based example), but be aware that it is interpreted as 00 == 0

Original comment by dstufft (Bitbucket: dstufft, GitHub: dstufft):

---

It's acceptable in that the version parsing will accept it, but it'll normalize it so that there is no leading zeros. I think this issue can be closed here since this is accurate with what PEP 440 says. If you think that PEP 440 should be adjusted please bring that up on distutils-sig as we're treating PEP 440 as provisional until we make sure all the issues get shaken out.

Original comment by mklein0 (Bitbucket: mklein0, GitHub: mklein0):

---

We can close this issue. I will bring up my example and ask for a clarification that the normalized version identifier will be used in package creation on distutils-sig. The use of the normalized version identifier in the packaging is another point of confusion. PEP 440 only referred to normalization in the context of parsing and processing, not in package creation.

[martinm82]

I know this issue is pretty old but I am totally confused about what PEP440 says and about how date based versions in reality work.

PEP 440 says

Date based release segments are also permitted. An example of a date based release scheme using the year and month of the release:
And as examples shows this:

2012.04
2012.07
2012.10
2013.01
2013.06

When using for example 2019.07 as a version I receive a warning saying

setuptools/dist.py:472: UserWarning: Normalizing '2019.07' to '2019.7' normalized_version

I am using setuptools 41.0.1

[jaraco]

PEP 440

[jaraco]

@dstufft, @ncoghlan How do you feel about updating the date examples in PEP 440 to elide the leading zeros?