-
-
Notifications
You must be signed in to change notification settings - Fork 5.7k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
In TestViewRepo2, convert computed timezones to local time #24579
Conversation
This fixes up go-gitea#10446; in that, the *expected* timezone was changed to the local timezone, but the computed timezone was left in UTC. The result was this failure, when run on a non-UTC system: Diff: --- Expected +++ Actual @@ -5,3 +5,3 @@ commitMsg: (string) (len=12) "init project", - commitTime: (string) (len=29) "Wed, 14 Jun 2017 09:54:21 EDT" + commitTime: (string) (len=29) "Wed, 14 Jun 2017 13:54:21 UTC" }, @@ -11,3 +11,3 @@ commitMsg: (string) (len=12) "init project", - commitTime: (string) (len=29) "Wed, 14 Jun 2017 09:54:21 EDT" + commitTime: (string) (len=29) "Wed, 14 Jun 2017 13:54:21 UTC" } Test: TestViewRepo2 I assume this was probably missed for the last couple months since the CI servers all run in UTC? The Format() string "Mon, 02 Jan 2006 15:04:05 UTC" was incorrect: 'UTC' isn't recognized as a variable placeholder, but was just being copied verbatim. It should use 'MST' in order to command Format() to output the attached timezone, which is what `time.RFC1123` has.
Wonder why @GiteaBot does not rebase here. Apparently I can't do it from GitHub UI either. |
Maintainers don't have push access here |
@kousu |
The fork is from an org. GitHub doesn't allow maintainer to edit the org fork's PRs. If I was the owner, I would merge this simple PR directly to save everyone's time. It doesn't make sense to wait again and again. |
Yep. I've run into this with every PR I've submitted to you so far. @jolheiser explained
So thank you for just going ahead and squash-merging it in. Plus I'm in a different timezone than most of you, so I wouldn't have gotten to it for a while! By the way,
Is this policy now? In this I was told off for using rebases:
|
* upstream/main: Add Gitea Profile Readmes (go-gitea#23260) Make diff view full width again (go-gitea#24598) Add permission check for moving issue action in project view page (go-gitea#24589) Update JS dependencies, add new eslint rules (go-gitea#24597) Filters for GetAllCommits (go-gitea#24568) [skip ci] Updated translations via Crowdin Attach a tooltip to the action control button (go-gitea#24595) Improve Gitea's web context, decouple "issue template" code into service package (go-gitea#24590) Support markdown editor for issue template (go-gitea#24400) Do not select line numbers when selecting text from the action run logs (go-gitea#24594) In TestViewRepo2, convert computed timezones to local time (go-gitea#24579) Fix close org projects (go-gitea#24588) Rewrite queue (go-gitea#24505) Split "modules/context.go" to separate files (go-gitea#24569) Pass 'not' to commit count (go-gitea#24473) Refresh the refernce of the closed PR when reopening (go-gitea#24231)
Don't rebase, lunny and silverwind meant |
Merge, yes. Gitea repo has a branch protection rule that a PR can only be merged when it is strictly descending off the |
I made a mistake and I have corrected it. |
This fixes up #10446; in that, the expected timezone was changed to the local timezone, but the computed timezone was left in UTC.
The result was this failure, when run on a non-UTC system:
I assume this was probably missed since the CI servers all run in UTC?
The Format() string "Mon, 02 Jan 2006 15:04:05 UTC" was incorrect: 'UTC' isn't recognized as a variable placeholder, but was just being copied verbatim. It should use 'MST' in order to command Format() to output the attached timezone, which is what
time.RFC1123
has.