Most changes to Python require a NEWS entry.

Please add it using the blurb_it web app or the blurb command-line tool.

All commit authors signed the Contributor License Agreement.

@malemburg (as the platform expert), would you mind to review and possibly merge this PR?

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

(I completely forgot about this PR, and was reminded of it today! Apologies)

@iritkatriel I'm a bit confused regarding how I am meant to create a unit test for this. This is a bug that only arises when Python (namely, the getbuildinfo module) is compiled with CFLAGS=-U__DATE__. This code path is not used by the preprocessor on any of the automated unit tests, so any unit test I do add will pass both before and after this PR....

Please rebase the PR for a review. Thanks.

(I completely forgot about this PR, and was reminded of it today! Apologies)

@iritkatriel I'm a bit confused regarding how I am meant to create a unit test for this. This is a bug that only arises when Python (namely, the getbuildinfo module) is compiled with CFLAGS=-U__DATE__. This code path is not used by the preprocessor on any of the automated unit tests, so any unit test I do add will pass both before and after this PR....

I understand. If you could just post here screenshots of before and after from your local build that would help us by creating a record of what the problem was.

The issue is that the platform.py parser expects the date string to only use \w chars. The "/" in the default string for __DATE__ causes it to fail. A possible unit test for this would to check whether the platform.py parser accepts the new default string "XXX XX XXXX".

Now, regarding the default string itself, I think it would be better to use a valid date string, since "XXX XX XXXX" will make platform.py's parser happy, but fail to parse as a date string downstream (in code using the platform.py python_build() API). "Jan 01 1970" would work (the Unix epoch).

On main:

$ ./python
Python 3.14.0a4+ (remotes/upstream/main:cdcacec79f, xx/xx/xx, xx:xx:xx) [GCC 14.2.1 20241221] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform
>>> platform._sys_version()
Traceback (most recent call last):
  File "<python-input-4>", line 1, in <module>
    platform._sys_version()
    ~~~~~~~~~~~~~~~~~~~~~^^
  File "/home/user/projects/cpython/Lib/platform.py", line 1201, in _sys_version
    raise ValueError(
        'failed to parse CPython sys.version: %s' %
        repr(sys_version))
ValueError: failed to parse CPython sys.version: '3.14.0a4+ (remotes/upstream/main:cdcacec79f, xx/xx/xx, xx:xx:xx) [GCC 14.2.1 20241221]'

On this branch:

$ ./python
Python 3.14.0a4+ (heads/fix-undefined-date:5d72c723dc, Jan 01 1970, 00:00:00) [GCC 14.2.1 20241221] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform
>>> platform._sys_version()
('CPython', '3.14.0a4+', 'heads/fix-undefined-date', '5d72c723dc', 'heads/fix-undefined-date:5d72c723dc', 'Jan 01 1970 00:00:00', 'GCC 14.2.1 20241221')

Now, regarding the default string itself, I think it would be better to use a valid date string, since "XXX XX XXXX" will make platform.py's parser happy, but fail to parse as a date string downstream (in code using the platform.py python_build() API). "Jan 01 1970" would work (the Unix epoch).

No objections to that. Done. Also, to keep it consistent, I changed the default time string from "xx:xx:xx" to "00:00:00" (so now the default is Unix epoch).

@iritkatriel Are you fine with this now ?

Yes, the bad output was posted in a comment.

Thanks, @fosslinux