JavaScript Error: Cannot Parse Date Format on Version 1.21.11 During Page Change in Milestones

[CasperHK]

Description:

During the page change in the Milestones section, a JavaScript error is encountered that states:

JavaScript error: Cannot parse: 10000-01-0

This error is thrown from the file webcomponents.js at the following URL:
https://10.11.20.95:3000/assets/js/webcomponents.js?v=1.21.11 at line 1,55713.

Steps to Reproduce:

1. Navigate to the Milestones section.
2. Attempt to change the page.
3. Observe the error in the browser console.

Expected Behavior:

The page should change without any JavaScript errors.

Actual Behavior:

A parsing error occurs, but the milestone list is loaded correctly.

Recommendation:

Check the date formatting in the data being passed to the JavaScript function. Ensure it conforms to a valid date format that can be parsed successfully.

Note:

Open the browser console for more details on the error message and stack trace.

Gitea Version

1.21.11

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

Git Version

No response

Operating System

Ubuntu

How are you running Gitea?

The Gitea is running on Ubuntu 20.04.3 as a systemd service.

Database

MySQL/MariaDB

[lunny]

If you cannot reproduce this on the demo site with the same repository or page, that commonly means this has been resolved by Gitea new stable versions. So that maybe you can try upgrade to v1.22

[yardenshoham]

Please run:

SELECT *
FROM "milestone"

[nnsee]

I'm having the exact same issue. The output of SELECT * FROM milestone; is as follows:

 id | repo_id |    name     |                                           content                                           | is_closed | num_issues | num_closed_issues | completeness | created_unix | updated_unix | deadline_unix | closed_date_unix 
----+---------+-------------+---------------------------------------------------------------------------------------------+-----------+------------+-------------------+--------------+--------------+--------------+---------------+------------------
  1 |      44 | CPE support | Full support for the Classic Protocol Extension: https://wiki.vg/Classic_Protocol_Extension | f         |         36 |                 0 |            0 |   1688473345 |   1688474665 |  253402300799 |                0

I only have one milestone. I'm on v1.22.

[yardenshoham]

Then it must not be the milestone deadline, probably another timestamp on that page.

[yardenshoham]

How to reproduce it?

[wxiaoguang]

But it is related to the milestone deadline.

You see, 253402300799 means 10000-01-01 (actually it is Fri, 31 Dec 9999 23:59:59 GMT, then the next second is 10000-01-01). The problem is why (and how) could you set it to a milestone and save it into database ....

Some guesses: from API? from some data migration? or some frontend behavior (JS uses millisecond)?

[wxiaoguang]

I guess I have a brief picture of the problem now.

In code, Gitea does use year 9999 as a special value to handle "deadline".

However, some recent frontend milestone date/time changes might break (unable to follow) this rule, maybe related to the relative-time/absolute-date component.

[wxiaoguang]

Maybe related to "Fix due date rendering the wrong date in issue (#26268)" and "Fix date rendering by adding <gitea-absolute-date> (#29725)"

The deadline's date 9999-12-31 23:59:59 (local timezone) is not able to be handled by the new code.

[yardenshoham]

cc @silverwind

[wxiaoguang]

After reading more context, I think the real problem is the bad design of "Deadline", which uses "9999-12-31". The bad design triggers the frontend bug (say, frontend code is not right either).

A complete fix should start from refactoring the "Deadline" field of the Milestone model. A quick fix could only bypass some edge cases.

[lunny]

Maybe we can use 0 for the deadline_unix in the milestone table as no deadline. As a migration, we could replace the value which is bigger than 253402099200 as 0 in the database.

[wxiaoguang]

The year "9999" in web/api was introduced in year 2014 (it doesn't seem reasonable), at the moment there is no migration using such value.

And the worst thing is, when 253402300799 is stored in database, it would be read and converted again and affected by timezone, so it could become early or late values other than 9999-12-33 23:59:59, and other logic also goes wrong.