Opened 3 years ago
Closed 5 months ago
#2016 closed task (fixed)
Review and improve date format strings
| Reported by: | str4d | Owned by: | zzz |
|---|---|---|---|
| Priority: | minor | Milestone: | 0.9.43 |
| Component: | apps/console | Version: | 0.9.30 |
| Keywords: | i18n usability time easy | Cc: | |
| Parent Tickets: | Sensitive: | no |
Description
http://trac.i2p2.i2p/ticket/1996#comment:15
The issue is not only translation but also formatting. We don't ever set the Locale in the JVM. You can either create a locale for the current translation setting (which we don't usually do) or use the JVM's Locale. To test with other locales, start the JVM with a command line option.
For simple format specs, it's been fine to specify them, but for longer ones, we risk it looking strange to some users as we impose what looks "right" to us. In that case, it's better to use the Locale-specific builtins.
If you like we can make a pass through the whole codebase grepping for SimpleDateFormat and trying to ensure even more consistency in formatting, translation, and timezone
There are several parts to this:
- Review usage of SimpleDateFormat and collate all the date format strings we use.
- Propose and implement usage-appropriate date format strings that are user-friendly and consistent.
- (Slightly harder) Implement localization of date format strings.
Subtickets
Change History (7)
comment:1 Changed 3 years ago by
| Milestone: | undecided → 0.9.32 |
|---|---|
| Status: | new → open |
comment:2 Changed 2 years ago by
| Milestone: | 0.9.32 → 0.9.34 |
|---|
@str4d awaiting your response, suggestions, or proposal, let's do whatever we're going to do for .34
comment:3 Changed 20 months ago by
| Milestone: | 0.9.34 → 0.9.36 |
|---|---|
| Owner: | set to zzz |
| Status: | open → accepted |
comment:4 Changed 20 months ago by
On a related note, the time formatting on /logs has 3 different variations; standardizing to a single format there would be an improvement.
comment:5 Changed 5 months ago by
| Milestone: | 0.9.36 → 0.9.43 |
|---|---|
| Sensitive: | unset |
I've settled on MEDIUM for date and SHORT for time, which looks like this:
ar 30/08/2019 12:38 م be 30.8.2019 12.38 bg 30.08.2019 12:38 ca 30/08/2019 12:38 cs 30.8.2019 12:38 da 30-08-2019 12:38 de 30.08.2019 12:38 el 30 Αυγ 2019 12:38 μμ en Aug 30, 2019 12:38 PM es 30-ago-2019 12:38 et 30.08.2019 12:38 fi 30.8.2019 12:38 fr 30 août 2019 12:38 ga 2019 Lún 30 12:38 hi Aug 30, 2019 12:38 PM hr 2019.08.30 12:38 hu 2019.08.30. 12:38 in 2019 Agu 30 12:38 is 30.8.2019 12:38 it 30-ago-2019 12.38 iw 12:38 30/08/2019 ja 2019/08/30 12:38 ko 2019. 8. 30 오후 12:38 lt 2019-08-30 12.38 lv 2019.30.8 12:38 mk 30.8.2019 12:38 ms 2019 Ogos 30 12:38 mt 30 Aww 2019 12:38 nl 30-aug-2019 12:38 no 30.aug.2019 12:38 pl 2019-08-30 12:38 pt 30/ago/2019 12:38 ro 30.08.2019 12:38 ru 30.08.2019 12:38 sk 30.8.2019 12:38 sl 30.8.2019 12:38 sq 2019-08-30 12.38.MD sr 30.08.2019. 12.38 sv 2019-aug-30 12:38 th 30 ส.ค. 2019, 12:38 น. tr 30.Ağu.2019 12:38 uk 30 серп. 2019 12:38 vi 12:38 30-08-2019 zh 2019-8-30 下午12:38
comment:6 Changed 5 months ago by
re: wrapper log (comment 4), it does not appear that the date format there can be customized.
https://wrapper.tanukisoftware.com/doc/english/prop-logfile-format.html
comment:7 Changed 5 months ago by
| Resolution: | → fixed |
|---|---|
| Status: | accepted → closed |
In cbc33073f5d6819d22055195e06a46e638abcf8a to be 0.9.42-2
The best practices we have now is to use either:
There's very few spots in the code for user-visible dates that use something different from those two.
My issue in #1996 comment 15 is the change went *widely* off-script from these two best practices, and that could easily be fixed before the .31 release, should you care to do so.
For reference, here's sample output for each format, for each locale:
The formatting we use _is_ localized. But it uses the JVM's locale, not the language configured in the console. That's a conscious decision, not an accident, but we could reconsider it.
We could, perhaps, add utility methods to DataHelper? or SystemVersion? to return the date, time, or datetime, in the local timezone and/or UTC. Might be helpful, might not. Whether the 1st or 2nd 'best practice' is the actual 'best' really affects, for example, how it looks in the US English locale - are you a MM/dd/yy hater or not. But to force YYYY-mm-dd on all locales may not be ideal either, as the chart above shows.
Also, took me a second, but 'collate' in OP 1st bullet means 'gather', not 'locale-dependent sorting'