Issue due date is always one day plus

[neolithos]

• 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

gitea/routers/api/v1/repo/issue.go

Lines 293 to 296 in 8917d66

	var deadlineUnix util.TimeStamp
	if form.Deadline != nil && !form.Deadline.IsZero() && ctx.Repo.CanWrite(models.UnitTypeIssues) {
	deadlineUnix = util.TimeStamp(form.Deadline.Unix())
	}

gitea/routers/api/v1/repo/issue.go

Lines 413 to 419 in 8917d66

	var deadlineUnix util.TimeStamp
	var deadline time.Time
	if form.Deadline != nil && !form.Deadline.IsZero() {
	deadline = time.Date(form.Deadline.Year(), form.Deadline.Month(), form.Deadline.Day(),
	23, 59, 59, 0, form.Deadline.Location())
	deadlineUnix = util.TimeStamp(deadline.Unix())
	}

Get

gitea/models/issue.go

Line 384 in 8917d66

apiIssue.Deadline = issue.DeadlineUnix.AsTimePtr()

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

[zeripath]

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.

[neolithos]

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]

What can I give, to resolve this issue?

[zeripath]

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.

[neolithos]

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:
neolithos@a125f88

Is this correct. Should I send this as pr?

[stale]

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.

[dimpfelmoser]

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

[6543]

@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 ...

[jswolf19]

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).

[LFriede]

Looks like this one is fixed in 1.12.0-rc2 by this PR #11697

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

[zeripath]

Closing as fixed by #11697