Display ui time with customize time location

[lunny]

• Add option on app.ini to set DEFAULT_UI_LOCATION, default is time.Local.
• Add language's default time format string, current support zh-CN, lv-LV, en-US and default is en-US.
• Render time according DEFAULT_UI_LOCATION and locale from users' setting or browser language.
• Move all time related functions to a new package modules/timeutil.

zh-CN

lv-LV

en-US and other languages

[silverwind]

Do I understand correctly that this would hardcode a certain client time zone on the server? I think it'd be better to just send UTC to the browser and do the timezone conversation there. I do have this handy JS function to convert either a Unix or ISO 8601 string to a local date, respecting the user's current time zone:

localtime = (datestr) => {
  if (!datestr) return null;
  if (typeof datestr === "number") datestr = new Date(datestr).toISOString();
  const date = new Date(datestr);
  const offset = (new Date()).getTimezoneOffset() * -60000;
  const ts = (date.getTime()) + offset;
  return new Date(ts).toISOString().substring(0, 19).replace("T", " ");
};

We could render UTC in the go template towards a <div data-unixtime="{unixtime}">{utc formatted}</div> and then do a JS-based replacement on page load. It's very similar to how GitHub does it, e.g. render a relative date if time difference is less than a month, otherwise absolute date in the user's timezone.

[lunny]

@silverwind that should be a better idea. That case, we need to render the time on browser but not server side.

[silverwind]

You can still render it on the server and then later replace them on the client. It's what GitHub does, so if you disable JavaScript, you will see the server-rendered dates.

[lunny]

@lafriks done.

[lunny]

Should fix #7723

[zeripath]

I think silverwind is correct here, it would still be useful to send the UTC time to the client for them to render as they see.

[lunny]

@silverwind @zeripath Since we can get lang, I have a new idea here and updated the PR. I found javascript's toLocalString is not always correct. So I prefer server-side render.

[codecov-io]

Codecov Report

Merging #7792 into master will decrease coverage by 0.02%.
The diff coverage is 56.86%.

@@            Coverage Diff             @@
##           master    #7792      +/-   ##
==========================================
- Coverage   41.42%   41.39%   -0.03%     
==========================================
  Files         476      478       +2     
  Lines       63849    63877      +28     
==========================================
- Hits        26450    26445       -5     
- Misses      33953    33982      +29     
- Partials     3446     3450       +4

Impacted Files	Coverage Δ
models/repo_unit.go	64.91% <ø> (ø)	⬆️
models/u2f.go	63.15% <ø> (ø)	⬆️
models/commit_status.go	72.22% <ø> (ø)	⬆️
models/lfs.go	32.72% <ø> (ø)	⬆️
models/admin.go	81.63% <ø> (ø)	⬆️
models/branches.go	49.15% <ø> (ø)	⬆️
models/attachment.go	52.05% <ø> (ø)	⬆️
models/topic.go	54.7% <ø> (ø)	⬆️
models/review.go	59.77% <ø> (ø)	⬆️
models/issue_stopwatch.go	71.05% <ø> (ø)	⬆️
... and 61 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5a44be6...b44d5c6. Read the comment docs.

[silverwind]

I found javascript's toLocalString is not always correct. So I prefer server-side render.

Might be. My concern was basically about offsetting time to the correct user timezone, which is something only the client can do as the server has no knowledge on the user's time zone. For that getTimezoneOffset should be the correct approach, and I think formatting would have to happen in JS too.

[guillep2k]

There's a hack I've used sometimes and it consists in sending the TZ offset from the browser to the server. Maybe in a cookie. It's not pretty, but it could be preferrable to some default. Check this (outdated) StackOverflow answer. But if you go saying that I've said this, I'll deny everything. 🙊

[lunny]

@silverwind @guillep2k That's not always user's want if he trip to other countries or other something. We finally will add an option on user settings to let people could chose his timezone and change it anytime he want.

[silverwind]

Sounds good. I would seed that setting with the current timezone from JS initially.

[guillep2k]

@silverwind @guillep2k That's not always user's want if he trip to other countries or other something. We finally will add an option on user settings to let people could chose his timezone and change it anytime he want.

@lunny I agree that a user setting is the best option... when available. But users might not be logged in, so it would be preferable to have some proper default for that situation.

Also, some users may actually want the dates shown in their current TZ, even if they are out of their country (I would). The browser's local time will reflect the user's choice in that regard, too.

What I'd do is:

1. Calculate a good default for pages served for anonymous users. This could be either Gitea's process TZ env variable, an app.ini setting or something calculated from the browser local time as proposed earlier.
2. The user, when logged in, can choose a different TZ, but automatic would be a valid option and work just like (1) when selected.

Thus most cases will be covered.

[silverwind]

Actually, it's probably always prefered to show time in the current timezone the user is in, I see no need for a user-specific setting. So:

• Send either server-configured time zone or UTC if absent to browser and render initially
• Perform JS conversation to current user timezone and replace rendered date.

For actual display, I would choose a simple format like YYYY-MM-DD HH:mm:ss with relative dates for short timespans. GitHub does relative dates for anything shorter then 30 days, which seems like a good default.