Opened 2 years ago
Last modified 15 months ago
#2016 accepted task
Review and improve date format strings
| Reported by: | str4d | Owned by: | zzz |
|---|---|---|---|
| Priority: | minor | Milestone: | 0.9.36 |
| 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 (4)
comment:1 Changed 2 years ago by
| Milestone: | undecided → 0.9.32 |
|---|---|
| Status: | new → open |
comment:2 Changed 18 months 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 15 months ago by
| Milestone: | 0.9.34 → 0.9.36 |
|---|---|
| Owner: | set to zzz |
| Status: | open → accepted |
comment:4 Changed 15 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.
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'