add timetzdata build tag to binary releases

[techknowlogick]

timetzdata is already used in the docker images, this includes them for the binary release files too.

Related to #33235 (I don't have a windows machine setup to test this though)

[wxiaoguang]

Thank you very much for the details. I just found a Go issue: time: add time/tzdata package and timetzdata tag to embed tzdata in program #38017, https://github.com/golang/go/issues/38017

According to the Go issue 38017, it seems that the problem is mainly related to Windows.

Maybe we could add a xxx_windows.go and use import _ "time/tzdata" there? It could save 800KB binary size for non-Windows build, and clearer to our build system (easy to add comments and fine tune and maintain in the future)

[silverwind]

Some more context from https://pkg.go.dev/time/tzdata:

If this package is imported anywhere in the program, then if the time package cannot find tzdata files on the system, it will use this embedded information.
Importing this package will increase the size of a program by about 450 KB.

We know some versions of Windows are affected, but it may affect others as well, like for example weird BSD variants etc. I think it's better to always include the fallback tzdata info. 450kB seems acceptable.

[silverwind]

Oh, and I think it would be great if we specify such default tags in Makefile instead of the actions, so that people who build from source can also benefit:

gitea/Makefile

Line 136 in 47bf836

TAGS ?=

[wxiaoguang]

We know some versions of Windows are affected, but it may affect others as well, like for example weird BSD variants etc. I think it's better to always include the fallback tzdata info. 450kB seems acceptable.

Why pay the cost which doesn't really affect?

On a slightly related note, I would like to see tags like this being specified as the default tags in Makefile here:

Why not just use xxx_windows.go / xxx_freebsd.go to import _ "time/tzdata"?

[silverwind]

We know some versions of Windows are affected, but it may affect others as well, like for example weird BSD variants etc. I think it's better to always include the fallback tzdata info. 450kB seems acceptable.

Why pay the cost which doesn't really affect?

On a slightly related note, I would like to see tags like this being specified as the default tags in Makefile here:

Why not just use xxx_windows.go / xxx_freebsd.go to import _ "time/tzdata"?

Because you can't know for certain whether a given OS has tzdata available. Let's say I compile a barebone Linux distro like Arch or Gentoo and forget to install that package. Gitea would not start up.

[wxiaoguang]

Because you can't know for certain whether a given OS has tzdata available. Let's say I compile a barebone Linux distro like Arch and forget to install that package. Gitea would not start up.

No, it WOULD start up. No timezone data affects nothing as long as the end user doesn't set it in their config.

[silverwind]

You mean #33235 (comment) does not happen in default config? Well, even if that's true, I think it's still good to include those 450kB just in case. This is only a 0.5% size increase assuming a 100mb binary.

[wxiaoguang]

You mean #33235 (comment) does not happen in default config? Well, even if that's true, I think it's still good to include those 450kB just in case. This is only a 0.5% size increase assuming a 100mb binary.

Your worry will never happen. Only Windows users need that timezone data.

• For a Linux user, if they set timezone manually but the OS doesn't contain tzdata: then they could realize that they need to install the tzdata package.
• For a Windows user: there is no way to install tzdata, so the tzdata must be packed into the binary.

[techknowlogick]

updated per @wxiaoguang feedback.

I chose settings module as location for import since we already have other conditional imports there, such as sqlite.

[wxiaoguang]

I will add some comments

[wxiaoguang]

Why the PRs are ALWAYS blindly merged without updating the title/description? Does the commit message match the commit change? @lunny