MIlestones with 2/29 due date display as 2/28

[janie314]

Description

As simple as it sounds. Create a milestone with due date 2/29/2024, and it will display as 2/28/2024.

Gitea Version

1.21.4

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

2.40.1

Operating System

Gentoo

How are you running Gitea?

Gentoo gitea package

Database

SQLite

[eeyrjmr]

uuur leapyear bug

[yardenshoham]

Hmmm I can't reproduce

Can you give a link to the demo site with reproduction?

[janie314]

See https://try.gitea.io/janie314/SDFSDF/milestones @yardenshoham

[yardenshoham]

Looks ok on my side

What's your timezone?

[techknowlogick]

Yup. This is based on timezone. The value is stored as a date in the db, but then the time library displays it as a datetime and due to midnight utc being different it shows as a different day.

[janie314]

I see- thanks all!

Looks like there is no per-user timezone setting for Gitea. I suppose we can either close this or leave this issue open as an enhancement request for that.

[techknowlogick]

I'd suggest keeping this open, as the due date should probably be treated as a date.

[yardenshoham]

How to reproduce? Should I set a different timezone in my OS? Currently on GMT+2

[techknowlogick]

@yardenshoham yeah, likely changing your timezone to any one lower than UTC-0. As then "midnight" utc will a different day.

[yardenshoham]

Thanks, I was able to reproduce. How should we handle this? Maybe parse the user's timezone and set the milestone to the user's midnight?

[janie314]

Hmhm. Currently, Gitea does not have an default timezone setting and uses its server's timezone, as I understand.

I suggest:

• Next to this date input (and other similar date inputs), we note the Gitea server's timezone (America/Chicago, UTC, etc.)

Because with the original issue submitted- the issue was that the date I chose was secretly converted to a date in the server's timezone. So- server-timezone dates are the dates we use, in reality, so just making a small note of that will be a straightforward resolution.

[lunny]

Or we can have a timezone selection near the date.

[yp05327]

issue also has dealine, maybe have same problem.

[silverwind]

I agree with #29034 (comment), we should reduce these datetime (yyyy-mm-dd HH:mm) in the database to date (yyy-mm-dd) via migration.