Default Date & Time format - conversational format

Development
,
#1

Hey everyone! :blush:

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:

  1. 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)”
  2. 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”
  3. 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
  4. 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)

What do you think about all of this? :thinking:

#2

For this part, it should be quite easy since we’re already using the PrettyTime library, see PrettyTime | OCPsoft

This looks too complex to me (it requires important maintenance) and also it doesn’t take into account extensibility and XWiki extensions.

Note that we already use conversational format in our data script service: $services.date.displayTimeAgo(...).

This is used in mention.vm but also in security vulnerability notifications and in notification dates. Possibly also in some contrib extensions idk.

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:

  1. Use the defined date format everywhere (and possibly use the conversational format by default)
  2. 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?

Thx for starting the discussion Adina!

#3

Confirmed, see https://github.com/search?q=org%3Axwiki-contrib%20displayTimeAgo&type=code

#4

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.

#5

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

Thanks,
Marius

#6

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

result is

image

which applies for livetable also

image

#7

Hey everyone,

Interesting suggestion! I ran into this recently when using the appwithinminutes Date Picker datevalue

image

Where getValue() results in

Sun Dec 01 10:30:00 CET 2024

Anyway +1 for the Initial proposal …

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.

+1 for option 1 of

Ah I should’ve read all the reactions first;

tl;dr I agree @mflorea 's conclusion!

#8

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.

+1 from me for both options