Views do not respect "Date format" setting in a "REST Export" display

Created on 2 February 2024, about 1 year ago

Problem/Motivation

I need to set a custom "Date format" for a field in a "REST export" display in a view.

Steps to reproduce

  1. Create a view with a "REST export" display.
  2. Use "Show: Fields"
  3. Add a date field, like "Content: changed"
  4. Configure the field with "Date Format: Custom" and any "Custom date format"
  5. Preview the view. Observe that the custom date format is ignored.
  6. Do the same with a "Page" display.
  7. Observe that the custom date format is not ignored on the page.

Or you can simply import the export views config I have attached.

Proposed resolution

The "REST export" display should respect the date format.

Merge request link

None yet.

Remaining tasks

TODO

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

TODO

🐛 Bug report
Status

Active

Version

10.2

Component
Views 

Last updated 1 day ago

Created by

🇿🇦South Africa rudolfbyker South Africa

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @rudolfbyker
  • 🇮🇳India Akhil Babu Chengannur

    Thanks for the detailed issue decsription. I tried to recreate this issue wirh the given view configuration in Drupal 10.2.2 & Drupal 11 versions and these are the observations.

    If custom date format is selected and 'U' is given as the format, Timestamp value of the date appeares correctly in the response.
    If another custom date format is used (Eg: m/d/Y), date gets correctly formated in the response.

  • 🇳🇱Netherlands Lendude Amsterdam
  • 🇿🇦South Africa rudolfbyker South Africa

    @Lendude those issues look similar, indeed, but they are marked as fixed, while I can still reproduce this issue by importing the attached `views.view.test.yml` file into a fresh Drupal 10.3.2 instance.

    @akhil babu you are correct. With the latest Drupal version, the "Date format" is respected, but the whole thing is still wrapped in HTML. I'll update the title and description of this issue.

    Partial workaround: Enable "Strip HTML tags" and "Remove whitespace" under "Rewrite results" when configuring the views field. The only problem is that it's still a string instead of an int when using "U" as the "Date format".

  • 🇿🇦South Africa rudolfbyker South Africa
  • 🇩🇰Denmark Steven Snedker

    @rudolfbyker has correctly identified a bug that should be squashed.

    When exporting your nodes as json, you'd probably want to be able to easily export your dates in some easily machine-readable format.

    For a project I'm currently working on
    05.12.2024 - 17:11
    is WAY superior to
    <time datetime="2024-12-05T17:11:05+01:00">05.12.2024 - 17:11</time>\n

    Silly workaround that works for me, but should only be temporary:
    In the view, configuring the date fields: rewrite the result. Remove HTML tags and trim it to 18 characters (no ellipsis).

    Another workaround:
    Ask for "raw output" at Format - Fields - Config.
    This will give you a timestamp, no HTML.

    The correct solution:
    Configuring the field, you should be able to set Formatter as "raw/no html markup"

  • First commit to issue fork.
  • 🇮🇳India niranjan_panem Gurugram

    Removed the tag for unix timestamp in views rest export, below is the patch for it.
    tag removed code

  • Pipeline finished with Failed
    2 months ago
    Total: 94s
    #410237
  • 🇩🇰Denmark Steven Snedker

    @niranjan_panem the patch in #10 is probably better than nothing, but a long term useful solution.

    Before patching:
    Ask for "raw output" at Format - Fields - Config. This will give you a timestamp, no HTML.

    After patching:
    Ask or Custom: U at Date Format. This will give you a timestamp, no HTML.

    What we need is
    The correct solution:
    Configuring the field, you should be able to set Formatter as "raw/no html markup"
    Default/Time Ago just doesn't cut it as formatting options.

  • The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

    This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

    Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Production build 0.71.5 2024