Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Due is shown incorrectly #21999

Closed
mrdunski opened this issue Dec 1, 2022 · 4 comments · Fixed by #22302
Closed

Due is shown incorrectly #21999

mrdunski opened this issue Dec 1, 2022 · 4 comments · Fixed by #22302
Labels
issue/confirmed Issue has been reviewed and confirmed to be present or accepted to be implemented type/bug
Milestone

Comments

@mrdunski
Copy link

mrdunski commented Dec 1, 2022

Description

The issue is here: https://try.gitea.io/pan_dunski/test/issues/1

I've chosen due as 2022-12-02 but after save it is converted to 2022-12-03

My timezone is CEST

Gitea Version

1.18.0+rc1

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

image

Git Version

No response

Operating System

No response

How are you running Gitea?

I'm using official chart with the following values:

image:
  repository: gitea/gitea
  pullPolicy: Always
  tag: "1.18.0-rc1"

Database

PostgreSQL

@wolfogre
Copy link
Member

Yeah, it's caused by mismatch timezones.

The exact due date is Fri, 02 Dec 2022 23:59:59 +0000, it's "+0000" because the timezone of try.gitea.io is UTC. and that means "2022-12-03" in CEST.

image

I know it's confusing, but it's not complicated to solve it, just set the timezone of the container to your preferred one.

@mrdunski
Copy link
Author

I think that's not the point. It uses different strategy (different time zone) in the time picker and the field. It is not confusing, but incorrect.

This is something new in 1.18, 1.17 works correctly with the same settings.

@wolfogre
Copy link
Member

wolfogre commented Dec 26, 2022

In 1.17 they did use the same timezone, until #21440.

@yardenshoham Any ideas?

@yardenshoham
Copy link
Member

Your explanation is correct. It's a timezone mismatch issue. The problem is that the Due Date field input uses UTC while it should be localized.

@yardenshoham yardenshoham added the issue/confirmed Issue has been reviewed and confirmed to be present or accepted to be implemented label Dec 26, 2022
@yardenshoham yardenshoham added this to the 1.18.1 milestone Dec 30, 2022
yardenshoham added a commit to yardenshoham/gitea that referenced this issue Jan 1, 2023
Backport go-gitea#22302

Previously, the last minute of the chosen date caused bad timezone rendering.

For example, I chose January 4th, 2023.

### Before
```html
<time data-format="date" datetime="Wed, 04 Jan 2023 23:59:59 +0000">January 5, 2023</time>
```

### After
```html
<time data-format="date" datetime="2023-01-04">January 4, 2023</time>
```

---

Closes go-gitea#21999

Signed-off-by: Yarden Shoham <hrsi88@gmail.com>
lunny pushed a commit that referenced this issue Jan 2, 2023
Previously, the last minute of the chosen date caused bad timezone
rendering.

For example, I chose January 4th, 2023.

### Before
```html
<time data-format="date" datetime="Wed, 04 Jan 2023 23:59:59 +0000">January 5, 2023</time>
```

### After
```html
<time data-format="date" datetime="2023-01-04">January 4, 2023</time>
```

---

Closes #21999

Signed-off-by: Yarden Shoham <hrsi88@gmail.com>
lunny pushed a commit that referenced this issue Jan 2, 2023
Backport #22302

Previously, the last minute of the chosen date caused bad timezone
rendering.

For example, I chose January 4th, 2023.

### Before
```html
<time data-format="date" datetime="Wed, 04 Jan 2023 23:59:59 +0000">January 5, 2023</time>
```

### After
```html
<time data-format="date" datetime="2023-01-04">January 4, 2023</time>
```

---

Closes #21999

Signed-off-by: Yarden Shoham <hrsi88@gmail.com>
@go-gitea go-gitea locked and limited conversation to collaborators May 3, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
issue/confirmed Issue has been reviewed and confirmed to be present or accepted to be implemented type/bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants