Page MenuHomePhabricator

Allow user-defined date format
Closed, ResolvedPublic


Upstreaming from

/settings/panel/account/ seems to only allow setting a custom Time Format, but not the Date Format (also tested this here in upstream).

Setting a custom format like Y-m-d H:i ends up with a duplicated date as the custom formatting is only appended:

Mon, Jun 9, 2014-06-09 12:08

I'm aware of T1321#12 for server config; however the user setting should be expanded to support not only editing the time format, but also the date format.

Revisions and Commits

Event Timeline

aklapper created this task.Jun 9 2014, 12:21 PM
aklapper raised the priority of this task from to Wishlist.
aklapper updated the task description. (Show Details)
aklapper added projects: Wikimedia, Phabricator.
aklapper added a subscriber: aklapper.
epriestley renamed this task from Allow user-defined time format to Allow user-defined date format.Jun 9 2014, 1:13 PM

T4660 is effectively the same, but this one has a slightly clearer description. See also discussion in See also T4661.

Some notes:

  • We have multiple different date formats for dates near and far from the current time ("Mon, June 9", "June 9 2012").
  • The date selection control can not reasonably respect a date format string.
  • All of the date formats we use are unambiguous (that is, no 3/4/2014) so they may not be preferred by all users, but shouldn't be unduly confusing.

None of this is too tricky, but a proper implementation involves multiple format controls for date strings, and additional format controls for the date picker control.

qgil moved this task to Details on the Wikimedia board.Jun 13 2014, 8:12 PM
Krenair added a subscriber: Krenair.Oct 3 2014, 3:02 PM
bd808 added a subscriber: bd808.Oct 3 2014, 3:29 PM

Even Randal Monroe agrees that ISO 8601 is the one true date format --

qgil updated the task description. (Show Details)Oct 3 2014, 6:13 PM
chad edited projects, added User Preferences; removed Phabricator.Nov 3 2014, 1:28 AM
Krenair claimed this task.Jan 2 2015, 4:26 PM
J5lx added a subscriber: J5lx.Jan 14 2015, 5:43 PM
joshuaspence updated the task description. (Show Details)Feb 26 2015, 1:16 AM
epriestley added subscribers: lpriestley, chad.

My primary concern here is that I strongly dislike adding options to the product (see T8227 for discussion). In most cases, I personally bear the brunt of the long-term cost of adding options.

The approach in D11155 resolves this by adding two new options ("recent date format", "not-so-recent date format"), and I worry it will imply a third option ("date selector order") and may lead to eventual introduction of a fourth option ("cutoff to switch between recent date format and not-so-recent date format").

I'd like to avoid this, so I prefer these approaches for UI formatting, from most-preferred to least-preferred:

  1. Close this as wontfix; the date format we use is already unambiguous and locale-neutral.
  2. Remove recent vs not-so-recnet dates so all dates have a consistent format; switch all dates to ISO 8601.
  3. Remove recent vs not-so-recent dates so all dates have a consistent format; provide a single option to customize it.
  4. Retain recent vs not-so-recent dates; provide two options (D11155).
  5. Retain recent vs not-so-recent dates; provide three options (formats, plus when we switch).
  6. Allow users to customize an arbitrarily large number of date formats based on how distant a date is.

I favor (1). I think (2) and (3) reduce "delight" and (4), (5) and (6) are not worth the effort and complexity. There's a slippery slope from (4) > (5) > (6), and (6) seems clearly terrible.

I'm fine with (3). I have a moderately strong preference for (3) over (4), (5), or (6). I don't think the "recent vs not-so-recent" feature is worth a config option (4) and definitely not worth two (5) or infinite (6).

If we do pursue (4), I think we should label these formats as "Short" / "Medium" / "Long" / "Full" or similar, and not specifically tie them to recency, and generally consider moving toward (3) (that is, fewer magical rules about which format is selected) to avoid moving toward (4) (that is, more configuration options around magic).

For the date-time selector:

  1. Close this as wontfix; the format we use is already unambiguous and locale-neutral.
  2. Reorder components to Y-m-d, provide no options.
  3. Provide an additional option, separate from any options provided above, to reorder components.
  4. Try to parse the options above to figure out how to reorder components; this won't always work and is generally a big mess and not really a practical solution.

I favor (1) here, too. I think (2) reduces "delight". I don't think (3) is worth the effort, and (4) is just bad from every perspective.

I'm fine with (3).

This isn't really a big deal, and my preference for throwing this in a hole and burning it isn't strong. These options are unlikely to cause an explosion in either engineering complexity or UI complexity. After D12881, date and time settings have their own panel, which further mitigates UI complexity. We almost certainly need to add more options here anyway for things which are not currently locale-neutral, like 12 hour vs 24 hour time.

This dovetails somewhat with T8060.

@chad, you tagged this with User Delight -- what's your preference in balancing these concerns?

@lpriestley, this overlaps at least somewhat with Calendar, particularly the date-time selector -- any thoughts here?

chad added a comment.May 22 2015, 4:02 PM

I would probably punt on this until we pursue true internationalization.

lpriestley added a comment.EditedMay 22 2015, 4:46 PM

I think we should wait until we implement T8060. There will, undoubtedly be some javascript unpleasanstries that will influence the level of customization allowed for this. If we push the user preference patch now, the most inconvenient outcome is that there might be a need to split out format customizations into date selection control format and timestamp format, which is too much preference noise, if we can avoid it. The best outcome, as far as date selection controls go, would be if we can improve and simplify the date selection control, then find a way for the user preference to be the master of both controls and timestamps.

My primary concern here is that I strongly dislike adding options to the product

There is no need to have options. Remove all options, use the one and only (T5296#78304).

qgil removed a subscriber: qgil.May 25 2016, 2:09 PM
epriestley closed this task as Resolved.Jul 13 2016, 5:16 PM

I'm just going to close this:

  • We now support European, US and ISO date formats for editing dates (configurable in Settings).
  • We can not support a wholly arbitrary format for editing dates because users could choose ambiguous nonsense which we could not parse.
  • We now support 12-hour and 24-hour time. There's one open bug with these (T10932) but that will be fixed separately.
  • When displaying dates in some contexts, we use one of these human-friendly formats. These formats are completely unambiguous in any locale:
    • Mon, Jan 1 (for recent dates)
    • Jan 1 2015 (for distant dates)

Use of human-friendly date formats like these is common in other popular web software and other similar suites (like Google, Twitter, Facebook, Amazon, Asana, Trello and GitHub). In most cases, I can't find a setting in any of these applications to switch to, e.g., ISO. I can find a few counterexamples (BitBucket uses ISO, JIRA uses 1/Jan/15) so this isn't universal, but some form of relative date format like this seems extremely common.

Based on poking around Wikipedia, even Mediawiki appears to use a format like this by default on the "View History" page ("1 Jan 2015"), although it has a setting which allows the user to switch to ISO or a small set of other predefined formats. Oddly enough, it does not appear to have an option to use 12-hour time, nor to list the time after the date. So I'd say Phabricator is not meaningfully less flexible than Mediawiki -- it has a similar number of total date display format options, they just let you configure slightly different things.

I also can't find a way to switch OSX to ISO. It offers a "United States (Computer)" region, but this region does not use ISO.

If you want to replace these relative dates with ISO dates, you can modify phutil_date_format() in libphutil (the location and behavior of this code may change in the future).

The most important aspect in flexibility is the ability to support all locales. MediaWiki uses a system largely based on PHP's date() for historical reasons, see Language::sprintfDate().

A modern application should rely on CLDR data: