Issue due date is always one day plus #2835

New Issue

GiteaMirror · 2025-11-02T04:50:19-06:00

GiteaMirror commented

2025-11-02 04:50:19 -06:00

Originally created by @neolithos on GitHub (Jan 29, 2019).

Gitea version (or commit ref): 8006b1b
Git version:
Operating system: Windows 2012 R2 (English, Timezone Germany/Berlin)
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant

Description

I set a issue due date, and it shows the date in views one day plus.

In the database I see the correct timestamp, 1549411199 -> 2019-02-05T23:59:59.
If I open the editor, there is also the correct stamp -> correct.
In issue overview, history and the issue it self I see the date always one day plus -> wrong.
Over due calculation -> correct.

Screenshots

Code

I would fix it, but I have no glue, what is indented. So, I give the lines they are responsible.

Save

8917d66571/routers/api/v1/repo/issue.go (L293-L296)

8917d66571/routers/api/v1/repo/issue.go (L413-L419)

Get

8917d66571/models/issue.go (L384)

AsTimePtr add's the local timezone, if i understand it correct.

Originally created by @neolithos on GitHub (Jan 29, 2019). - Gitea version (or commit ref): 8006b1b - Git version: - Operating system: Windows 2012 R2 (English, Timezone Germany/Berlin) - Database (use `[x]`): - [ ] PostgreSQL - [ ] MySQL - [ ] MSSQL - [x] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [x] No - [ ] Not relevant ## Description I set a issue due date, and it shows the date in views one day plus. - In the database I see the correct timestamp, 1549411199 -> 2019-02-05T23:59:59. - If I open the editor, there is also the correct stamp -> correct. - In issue overview, history and the issue it self I see the date always one day plus -> wrong. - Over due calculation -> correct. ## Screenshots ![issue_due](https://user-images.githubusercontent.com/9724420/51923315-fcac9900-23ea-11e9-8cc6-59ae4d551805.png) ## Code I would fix it, but I have no glue, what is indented. So, I give the lines they are responsible. ### Save https://github.com/go-gitea/gitea/blob/8917d66571a95f3da232a0c27bc1300210d10fde/routers/api/v1/repo/issue.go#L293-L296 https://github.com/go-gitea/gitea/blob/8917d66571a95f3da232a0c27bc1300210d10fde/routers/api/v1/repo/issue.go#L413-L419 ### Get https://github.com/go-gitea/gitea/blob/8917d66571a95f3da232a0c27bc1300210d10fde/models/issue.go#L384 `AsTimePtr` add's the local timezone, if i understand it correct.

GiteaMirror added the issue/confirmed label 2025-11-02 04:50:19 -06:00

GiteaMirror closed this issue

2025-11-02 04:50:19 -06:00

GiteaMirror commented

2025-11-02 04:50:20 -06:00

@zeripath commented on GitHub (Jan 30, 2019):

It's intended that the deadline should be the end of the day so the raw deadline datetime has 23:59:59 added to it.

It sounds like the deadline date isn't being corrected for your timezone. Of course, I'm on GMT so I can't easily replicate this... In fact it looks like your server thinks it's in UTC so it's reporting a deadline datetime that would push it into the next day for you.

@zeripath commented on GitHub (Jan 30, 2019): It's intended that the deadline should be the end of the day so the raw deadline datetime has 23:59:59 added to it. It sounds like the deadline date isn't being corrected for your timezone. Of course, I'm on GMT so I can't easily replicate this... In fact it looks like your server thinks it's in UTC so it's reporting a deadline datetime that would push it into the next day for you.

GiteaMirror commented

2025-11-02 04:50:20 -06:00

@neolithos commented on GitHub (Jan 31, 2019):

Then AsTimePtr is the wrong function to decode the unix time.
Because, this function adds the local time zone. And this is +1h, the next day.

@neolithos commented on GitHub (Jan 31, 2019): Then `AsTimePtr` is the wrong function to decode the unix time. Because, this function adds the local time zone. And this is +1h, the next day.

GiteaMirror commented

2025-11-02 04:50:20 -06:00

@neolithos commented on GitHub (Feb 3, 2019):

What can I give, to resolve this issue?

@neolithos commented on GitHub (Feb 3, 2019): What can I give, to resolve this issue?

GiteaMirror commented

2025-11-02 04:50:20 -06:00

@zeripath commented on GitHub (Feb 4, 2019):

Heya, sorry was busy with other things. Feel free to put a pr up. I guess the question is how to test this what we don't want is to be in the opposite situation.

My personal feeling is that we shouldn't be using datetimes to represent dates so if I get involved in writing a pr those will have to die.

Sorry fat fingers with the close.

@zeripath commented on GitHub (Feb 4, 2019): Heya, sorry was busy with other things. Feel free to put a pr up. I guess the question is how to test this what we don't want is to be in the opposite situation. My personal feeling is that we shouldn't be using datetimes to represent dates so if I get involved in writing a pr those will have to die. --- Sorry fat fingers with the close.

GiteaMirror commented

2025-11-02 04:50:21 -06:00

@neolithos commented on GitHub (Feb 4, 2019):

My go-lang knowledge are basicly zero, I can only help to build the master and test the solution.

But I picked a little bit around:
a125f886a8

Is this correct. Should I send this as pr?

@neolithos commented on GitHub (Feb 4, 2019): My go-lang knowledge are basicly zero, I can only help to build the master and test the solution. But I picked a little bit around: https://github.com/neolithos/gitea/commit/a125f886a8d9ddc18cf96e1924c03c72d7c75f58 Is this correct. Should I send this as pr?

GiteaMirror commented

2025-11-02 04:50:21 -06:00

@stale[bot] commented on GitHub (Apr 5, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Apr 5, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

GiteaMirror commented

2025-11-02 04:50:21 -06:00

@dimpfelmoser commented on GitHub (May 11, 2020):

As of today I am still stumbling over this problem. Gitea Version: 1.11.4.

A simple solution would be to add 12:00 hours to the date rather than 23:59:59.

Then the timezone can shift 11:59:59 in both directions.

The time per se is not needed anyways, only the date.

deadline = time.Date(form.Deadline.Year(), form.Deadline.Month(), form.Deadline.Day(), 
 		12, 00, 00, 0, form.Deadline.Location())

I do not know how to create PRs.

Marc

@dimpfelmoser commented on GitHub (May 11, 2020): As of today I am still stumbling over this problem. Gitea Version: 1.11.4. A simple solution would be to add 12:00 hours to the date rather than 23:59:59. Then the timezone can shift 11:59:59 in both directions. The time per se is not needed anyways, only the date. ``` deadline = time.Date(form.Deadline.Year(), form.Deadline.Month(), form.Deadline.Day(), 12, 00, 00, 0, form.Deadline.Location()) ``` I do not know how to create PRs. Marc

GiteaMirror commented

2025-11-02 04:50:21 -06:00

@6543 commented on GitHub (May 11, 2020):

@dimpfelmoser https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request can help you :)

and for the issue 🤔 instead of calculating afterwards, we may should calculate the correct time on due-date creation and insert this one ...

@6543 commented on GitHub (May 11, 2020): @dimpfelmoser <https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request> can help you :) and for the issue 🤔 instead of calculating afterwards, we may should calculate the correct time on due-date creation and insert this one ...

GiteaMirror commented

2025-11-02 04:50:21 -06:00

@jswolf19 commented on GitHub (May 14, 2020):

Is there a compelling use case to include time (as in, is the time being used somewhere?)? I think it would be easier to consider this a date unless there is a compelling reason to include time.
If the time is necessary, then perhaps a timezone setting per repository or org. or whatever is necessary (if it doesn't already exist).

@jswolf19 commented on GitHub (May 14, 2020): Is there a compelling use case to include time (as in, is the time being used somewhere?)? I think it would be easier to consider this a date unless there is a compelling reason to include time. If the time is necessary, then perhaps a timezone setting per repository or org. or whatever is necessary (if it doesn't already exist).

GiteaMirror commented

2025-11-02 04:50:22 -06:00

@LFriede commented on GitHub (Jun 10, 2020):

Looks like this one is fixed in 1.12.0-rc2 by this PR https://github.com/go-gitea/gitea/pull/11697

I was affected by this bug and it's working for me since I updated to 1.12.0-rc2

@LFriede commented on GitHub (Jun 10, 2020): Looks like this one is fixed in 1.12.0-rc2 by this PR https://github.com/go-gitea/gitea/pull/11697 I was affected by this bug and it's working for me since I updated to 1.12.0-rc2

GiteaMirror commented

2025-11-02 04:50:22 -06:00

@zeripath commented on GitHub (Jun 11, 2020):

Closing as fixed by #11697

@zeripath commented on GitHub (Jun 11, 2020): Closing as fixed by #11697

GiteaMirror referenced this issue

2025-11-02 12:14:53 -06:00

[PR #2835] [MERGED] Fix order of comments #16623

GiteaMirror referenced this issue

2025-11-02 12:14:57 -06:00

[PR #2839] [MERGED] Fix order of comments (#2835) #16626

Sign in to join this conversation.