I was thinking of changing the default date & time format from just having the date in full numbers to having the date in a format more natural to natural speaking:
Initial proposal
current format look: 10/23/2023, 8:00
proposed format look: 10 October 2023, 8:00 ( which is dd MMMM yyyy, HH:mm ) - conversational format
Why even have a conversational format
Having the date & time in this format creates an actual meaning. The meaning is given by the viewerâs perception on the date.
These perceptions will be made in either format, but in the current one, the viewer needs to actually do a little work that may involve human error:
forgetting for a second that October is the 10th month happens,
making wrong computations on how much time has passed since a page has been edited can happen,
checking the date to see if something was yesterday or not can be very much needed, etc.
These problems would be better tackled in the next section:
Going further - Full conversational format requirements
If weâd like to go further, we could improve how this information is rendered in the header of a page:
If today is 10 October and user A is looking at a page last modified on 9 October, he shouldnât see âLast modified on 9 Octoberâ, but just: âLast modified yesterdayâ.
The general cases would become:
if the modification was made in the same day with the viewing, the viewer should only see the number of hours since the modification: âtoday, at 13:13 (5 hours ago)â
if the action was made a day before the viewing (before 12 am of the current day), the viewer should only see: âyesterday, at 13:13â
if the action was made the same year as the viewing, the viewer should only see âon 11 July, at 13:13 (4 months ago)â - no need for the year
if the action was made at least 12 months before the viewing, the viewer should see âon 11 October 2022, at 13:13â
The case in which a format falls would be decided based on some small verification inside an if/switch block.
Configuring conversational format
This concerns the âGoing furtherâ requirements, not the initial proposal.
Ideally, one could configure where would they use this format. I can imagine seeing the conversational format useful in the header of the document, but not as useful or maybe even annoying in live data tables. Or⌠maybe someone sees them useful everywhere, not only in the header and wants to stay cohesive.
I propose having a list of checkboxes with options regarding where to use the conversational format. This list would come after the date & time format in Global Administration. The options would be:
(checked by default) in the document header
in all live data tables
in the information tab
+checkboxes for any other case ( Iâd need help identifying where do we use dates in places different than the ones added above)
So this means that today, there are at least 3 places in XWiki where the default time format is not used and thus not customizable by the admin users.
Thus, I think we have 2 options:
Use the defined date format everywhere (and possibly use the conversational format by default)
Define 2 date formats in the Admin UI for 2 types of use cases, and then itâs up to the code to decide which one to use.
Note that option 2) means introducing new date apis and possibly deprecating existing ones, so itâs not a super simple solution (which doesnât mean itâs not the right one ;)).
First, do we agree that Admin users should be able to customize the date format in all places or not?
I disagree with all of these points. Because the XWiki viewer is usually a guest or regular user who has limited rights to perform certain actions. Most admins or creators know all these things. And they develop custom queries or code where to provide desired mask to format the date.
For me, if weâre talking about just displaying in XWiki then it can be done by overwriting several templates files but it might be complex and significant amount of work.
I think we should have a single configurable date format (Iâm fine to switch to dd MMMM yyyy, HH:mm by default), but we should display the dates using âtime agoâ (pretty time) style where it makes sense AND when we do this we should always show the actual date as hint (with the title attribute, using the configured date format).
Note that in some places, like the PDF export, where the dates are displayed once and never updated, we shouldnât use the time ago style because the time when the dates were displayed (e.g. when the PDF was generated) is not always obvious to the user. In the case of the PDF export there are some parts like the cover page, header, footer, that are controlled by the PDF template, where we can show absolute dates (using the configured date format). But the PDF template doesnât control the exported content, so we may need a way to switch from âtime agoâ to absolute time âgloballyâ while exporting the content to PDF.
Thus, in the end we might need:
a string configuration property for the date format
a boolean configuration property for enabling / disabling the âtime agoâ style
In addition to my previous comment. Iâve changed the format of date in XWiki Preferences Content â Localization â Date / Time and provided this mask E MMM dd yyyy
the going further looks interesting also , +1 for the âtoday / yesterdayâ addition and omitting the year if itâs the current one. Iâd suggest the addition of timesince data should be optional however.
Hi again, I remembered that I had recently been trying to do some minor date operations on mine XWiki, to represent differences in milliseconds in more UI info, like days, months, and years.
Then I discovered a useful method $date.whenIs($creationDateOfDocument).full which can provide a desired input years or weeks or ⌠ago depending on configuration. But AFAIU XWiki is using 3.2 VelocityTool and regarding official documentation of Apache Velocity it can be customized, but XWiki doesnât have implementation of VelocityView which is responsible for text representation.
Currently, if you call this method with full attribute youâll receive only the first closest difference between before and now - it can be a year or month or days.
OMV, if to to allow such configuration for in XWiki it might be same as this proposal.
