Opened 19 months ago
Last modified 8 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: |
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 (add)
Change History (4)
comment:1 Changed 18 months ago by zzz
- Milestone changed from undecided to 0.9.32
- Status changed from new to open
comment:2 Changed 11 months ago by zzz
- Milestone changed from 0.9.32 to 0.9.34
@str4d awaiting your response, suggestions, or proposal, let's do whatever we're going to do for .34
comment:3 Changed 8 months ago by zzz
- Milestone changed from 0.9.34 to 0.9.36
- Owner set to zzz
- Status changed from open to accepted
comment:4 Changed 8 months ago by Reportage
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'