Restore ability to customize date format

[bakerkretzmar]

Nova 4 removed the ability to use custom date formats for Date and DateTime fields (docs).

For forms that makes sense, but it would be great to still be able to format the displayed date on Index and Detail pages.

Nova 3

Nova 4

[wdelfuego]

Some things I've tried that didn't work:

• Use the resolveUsing() method on the DateTime field to change what value is passed to the front-end (see https://nova.laravel.com/docs/4.0/resources/fields.html#field-resolution-formatting)
• Use the displayUsing() method on the DateTime field to change what value is shown on the index/detail page (see https://nova.laravel.com/docs/4.0/resources/fields.html#field-resolution-formatting)
• Directly pass a resolve function as a third argument to the constructor of the DateTime field

In all cases the field simply shows 'Invalid DateTime' in the front-end.

It seems that the front-end for Nova 4 is built to expect timestamps in specific formats (either $carbon->toIso8601String() or $datetime->format(DateTimeInterface::ATOM)) and that date/time formatting logic happens strictly on the client.

That's all fine and dandy, but it's hard for me to accept that Nova 4 has launched without such a basic feature as datetime formatting.

I'm getting Nova 2.0 dejavu, where we waited almost 3 years for a fix to a comparable issue - while third parties solved it perfectly - which was finally resolved by adding pickerDisplayFormat() to Nova 3.0 and telling everyone to upgrade. Now that we've paid for another upgrade to 4.0 pickerDisplayFormat() has been removed again...

I agree with OP that the picker isn't the most important, but we really should be able to format timestamps on Index and Detail pages.

I hope someone from the Nova team can tell us what to realistically expect with regard to this feature so we can all start using custom Datetime fields if need be.

[wdelfuego]

In my opinion, it would be more correct to change this issue back to a bug instead of a feature request since DateTime formatting in the Index and Detail views has been available to us without issues in Nova 3 and it seems a fair expectation for such basic functionality to be maintained, especially since the documentation mentions no such limitations.

The text above this Discussion ("bakerkretzmar started this conversation in Ideas & Feature Requests") is not correct, this was reported as a bug in the first place and then turned into an idea/feature request by a maintainer.

[wdelfuego]

@davidhemphill Could you let us know your stance on the issue of formatting DateTime fields on Index and Detail views? It's hard to imagine this being very complicated but maybe we're missing something here.

If it's not considered a bug, at least it should be considered a documentation issue because the documentation on Field Resolution/Formatting doesn't seem to apply to DateTime fields (causes 'Invalid DateTime' to appear in the front-end) and the Date Fields documentation doesn't mention the lack of formatting possibilities or how to customize the formatting. This is unpractical, but I also think it's unfair to paying users expecting basic features to survive major version bumps.

I would like to know if the Nova team agrees that this should be considered a bug and if there is any indication as to when the feature will be back in Nova 4. Thanks!

[Sotiris-k]

I also hope that this is a bug and that the datetime fields should be able to be formatted like all the other fields.

The format that it's using at the moment is, to say the least, highly impractical and layout breaking.

[davidhemphill]

We make extensive use of computed fields on the Nova site itself just for this purpose.

Text::make('Created At')
    ->exceptOnForms()
    ->displayUsing(fn ($d) => $d->diffForHumans());

To make this kind of thing a little nicer, Fields are Macroable. So you can shorten it to something like this:

// Put this in the boot method of a Service Provider
Field::macro('withFriendlyDate', function () {
    return new MergeValue([
        $this->onlyOnForms(),
        Text::make($this->name)
            ->exceptOnForms()
            ->displayUsing(fn ($d) => $d->diffForHumans())
    ]);
});

// Usage
DateTime::make('Created At')
    ->filterable()
    ->withFriendlyDate(),

[wdelfuego]

Thanks for the examples, David! Might be valuable to add to the documentation.

I'm already using the first work-around you proposed; a text field with a computed value works for display, but you lose the possibility to sort by the date field because you can't sort computable fields (right?).

Does the second solution with the Macro maintain sortability?

[davidhemphill]

If you use sortable in the computed Text field it will be sortable.

[clementmas]

$this->onlyOnForms() doesn't work when this code is added to NovaServiceProvider. Is there a typo or I'm missing something?

[keizah7]

$this->onlyOnForms() doesn't work when this code is added to NovaServiceProvider. Is there a typo or I'm missing something?

did you imported all namespaces?

use Laravel\Nova\Fields\Field;
use Illuminate\Http\Resources\MergeValue;
use Laravel\Nova\Fields\Text;


Field::macro('formatAsStandart', function () {
    return new MergeValue([
        $this->onlyOnForms(),
        Text::make($this->name, $this->attribute)
            ->exceptOnForms()
            ->displayUsing(fn ($value) => $value->format('Y-m-d'))
    ]);
});

[keizah7]

If you use sortable in the computed Text field it will be sortable.

sortable not working. v4.23.0

Works only with:

Date::make(__('Valid from'), 'valid_from')
    ->filterable()
    ->exceptOnForms()
    ->sortable()
    ->rules('nullable', 'date')
    ->displayUsing(fn ($value) => $value ? $value->format('Y-m-d') : ''),

macro breaks it

[wdelfuego]

With regard to the workarounds provided by @davidhemphill in the previous comment;

Adding sortable to the computed Text field without using the macro doesn't work.
Adding sortable to the computed Text field within the macro does work, that's nice!

Some things still bit me;

• the macro you supplied doesn't play well with localized field names; $this->name can be a localized value and the internal attribute name can't reliably be deduced from that
• the macro returns a MergeValue so it breaks method chaining in the Nova resource
• for that same reason, sortable had to be added to the Text field within the macro, but I don't want the macro that is responsible for date formatting to decide whether or not the column is sortable, I also don't want to add an argument to the macro because calling withDateFormat('d-m-Y', true) for sortable and withDateFormat('d-m-Y', false) for not-sortable columns is unreadable and unelegant, and I don't want to have separate date formatting macros to distinguish between sortable and unsortable columns either, but due to the previous point (returns MergeValue) I can no longer set sortable() in the Nova resource itself.

While I understand the elegance of using a MergeValue for auto-showing the actual DateTime field and auto-hiding the computed field on forms, those drawbacks are unacceptable to me so I'd prefer to lose the MergeValue and do the showing/hiding of fields manually in the Resource itself.

So, I adapted the macro as follows (I put this within the NovaServiceProvider::boot method):

Fields\Field::macro('withDateFormat', function ($format) {
    return Fields\Text::make($this->name, $this->attribute)
        ->exceptOnForms()
        ->displayUsing(fn ($d) => $d->format($format));
    });

And then defined my sortable DateTime field in the Nova resource as follows:

Fields\DateTime::make(__('Starts at'), 'starts_at')
    ->filterable()
    ->withDateFormat('d-M-Y, H:i')
    ->sortable(),
Fields\DateTime::make(__('Starts at'), 'starts_at')
    ->onlyOnForms(),

(Don't forget to use Laravel\Nova\Fields in both the NovaServiceProvider and the Nova resource for this code to work as-is).

I now have to define the field twice but that's a small price to pay for customizable DateTime formatting that plays well with localization, sorting and method chaining in the Resource class.

I am still groping in the dark as to why we can't simply define how a DateTime field is rendered in the front-end and I insist that having to resort to this macro trickery and doubly defined fields is a workaround, not a true solution, but it is a good workaround that really takes the pressure off needing a native formattable DateTime field.

@davidhemphill, you haven't replied to any of the criticisms put forward in this issue and that's fine, but I hope we agree that there is still at the very least a documentation issue -- in my opinion, it shouldn't be this hard to discover how to make a sortable column of formatted DateTime fields in a paid-for admin panel. I hope a real solution comes along someday or that the documentation will be updated to inform other users of how to approach the issue.

Having said that, it's completely understandable that Nova 4 is very new and that we have to discover these types of things together. Thanks for putting me in the right direction with the macro suggestion!

Update: Filtering the field breaks when not using the MergeValue approach or when using the MergeValue approach and adding the field a second time just for the form views.

[Sotiris-k]

So we lost the plain and simple DateTime format method to this?

This is a downgrade, is it not?

This makes me all the more curious to know the reasons behind this decision.

[wdelfuego]

It absolutely is, and not just because it's a convoluted approach, the workaround effectively breaks filterability.
Even when using the MergeValue approach, filterability breaks when you add the field a second time with the onlyOnForms qualifier.

You can add the macro from my comment and use it on Date fields to solve the formatting problem, but you now have to choose between either 1) not being able to filter the column in the Index view using the filterable option 2) or not being able to change the value on the Forms view.

Since the second is almost always unacceptable we effectively have a workaround that breaks default filterability support (adding a custom filter might still work well, haven't tried that yet).

[wdelfuego]

I've wrapped up this workaround into a separate composer package that also adds 5 custom filters so we can have custom DateTime formats, sortability and filtering at the same time. I think that solves this issue for now.

Installation and usage: wdelfuego/nova4-formattable-date

Let me know if you run into any problems using that package.

[crynobone]

You should be able to use displayUsing() on DateTime field starting from 4.2.4:

DateTime::make('Created At')->displayUsing(fn ($value) => $value->diffForHumans()),

[nrueckmann]

We are missing this feature too. It's really cumbersome to maintain an application using nova as admin UI when major releases strip down basic features like this.

[davidhemphill]

This method solves displaying the value on an item. But before creation, the datepicker is not formatted, nor do you have the option to to stuff like firstdayofweek(). Any thoughts on that?

The datepicker is formatted according to the locale of the given user and this is handled by the operating system, not Nova. Are you finding that the correct day of the week is not being displayed for you even if your locale is set to something that should display it otherwise?

[Sotiris-k]

A lot of people are using en-US just because they want to use a browser in English. Me included and I'm Greek.

However the default date format for en-US is mm/dd/yyyy which isn't used globally.

Trusting the OS locale for things other than strictly language is not trustworthy nor it is a common case in at least the rest of the world other than the US.

[nrueckmann]

The datepicker is formatted according to the locale of the given user and this is handled by the operating system, not Nova. Are you finding that the correct day of the week is not being displayed for you even if your locale is set to something that should display it otherwise?

That does not seem to work. Additionally to the client, Laravel is configured to use "de" locale.

[simpsons310]

This method solves displaying the value on an item. But before creation, the datepicker is not formatted, nor do you have the option to to stuff like firstdayofweek(). Any thoughts on that?

A bit of late, but is this fixed? i'm using 4.13.0 and it seems not have any change about this

[gregfrith]

Newbie here, just learning Laravel and nova after years of other Frameworks. Quite surprised there is no simple way to format a date or date and time, it would seem a very basic feature, even more surprised to learn such a feature used to exist. In fact, I originally googles and found the ->format() method, not realising e solution related to a previous version of Nova, and not until the code threw an exception and I investigated further did I know. Surely such a basic feature must come back? Can we have some feedback from the Nova team please?

:wq

[davidhemphill]

Please see: #3929 (comment)

[gregfrith]

Thanks @davidhemphill, I missed that this was a working solution. Got it working now.

:wq

[chimit]

Am I right that there is still no reliable way of setting the date format globally once and for all (dates and date pickers) and also no way of setting it per user?

Is it possible to get the date format from the user locale with a fallback from config('app.locale'), @davidhemphill? With an option to customize this behavior in a way similar to how we set timezones:

Nova::userTimezone(function (Request $request) {
    return $request->user()->timezone ?? config('app.timezone');
});

[sfinktah]

This seems to be much ado about nothing. The real issue is that there isn't a dedicated Vue component formatting the date (ala Facebook) in the Display view.

I have had no issues with formatting, sorting, filtering or other similar matters, using this simple hack. Note: there is probably a better way to detect the request type, but Nova doesn't appear to be exposing it.

    Date::make('Created')->sortable()->displayUsing(function(Carbon $d) use ($request) {
        switch(get_class($request)) {
            # We can get Index and Display views from the class name, the others are problematic
            case "Laravel\Nova\Http\Requests\ResourceIndexRequest":
                return $d->diffForHumans();
            case "Laravel\Nova\Http\Requests\ResourceDetailRequest":
                # Prints something like: Wednesday 19th of October 2022 08:40:48 AM UTC
                return $d->format('l jS \o\f F Y h:i:s A T');
            default:
                return $d;
        }
    }),

And there is definately a "bug report/issue" component to all of this, because I too am seeing the date in American (MM/DD/YYYY) form, but that appears to be an issue with luxon.

> luxon.DateTime.now().toLocaleString({
        year: 'numeric',
        month: '2-digit',
        day: '2-digit',
      })
'02/12/2023'

I am not American, and the only regional settings on my PC (Windows 10/Chrome) are American English and American Keyboard. The date should most definately be in DD/MM/YYYY form, if it has to be something other than 2023-12-02.

This however, appears to be a browser limitation (there doesn't appear to be any supported method for browsers to interpret the date/time regionalisation setting).

> Intl.DateTimeFormat().resolvedOptions()
{
    "locale": "en-US",
    "calendar": "gregory",
    "numberingSystem": "latn",
    "timeZone": "Australia/Sydney",
    "year": "numeric",
    "month": "numeric",
    "day": "numeric"
}

So language choice (I assume) = locale = how you see dates.

I would change languages to see if it alters the resultant output -- I'm sure it would -- but that involves a log-out and log-in.