datetime-local HTML5

[alexbowers-tecmark]

HTML5 datetime-local input field requires the format to be:

• A date.
• The literal string "T".
• A time.

This can be done with formatting, but having a ->toDatetimelocal() would be useful.

I couldnt find anything that already does this in the documentation.

http://www.w3.org/TR/html-markup/input.datetime-local.html

[briannesbitt]

See : http://carbon.nesbot.com/docs/#api-commonformats

echo $dt->toW3cString(); // 1975-12-25T14:15:16-05:00

[alexbowers-tecmark]

Thanks

[tevfik6]

Hi @briannesbitt,

It seems like this is not working anymore. I'm getting warning from Chrome Version 51.0.2704.103 (64-bit) and input[type="datetime-local"] doesn't show anything. It looks like it can't even parse this.

The specified value "2016-07-28T01:02:00+00:00" does not conform to the required format. The format is "yyyy-MM-ddThh:mm" followed by optional ":ss" or ":ss.SSS".

Tev.

[bjuppa]

Hi!
It could make sense to reopen this request! The HTML5 datetime input is happy with the toW3cString() format, but datetime-local requires another similar format, up to but completely without the timezone info.

Current workaround is to use $dt->format('Y-m-d\TH:i:s')
Could toDatetimelocalString() be a suitable name to match the others in http://carbon.nesbot.com/docs/#api-commonformats?

[papalardo]

toDateTimeLocalString() works to me

[bjuppa]

Until just now I wasn't even aware there had been a PR for this suggestion merged over a year ago! I'm so glad to see it in there, thanks to @yamenarahman!

[yamenarahman]

You’re welcome.

[weshooper]

A specific format for this would still be useful.

While toDatetimelocalString() does work, Chrome/Brave pickup the seconds and confusingly render them:

A format without the seconds (i.e. a shortcut for ->format('Y-m-d\TH:i') would be handy, since it'd render as:

[kylekatarnls]

Macro?

Carbon::macro('pickerFormat', static function () {
  return self::this()->format('Y-m-d\TH:i');
});

echo Carbon::now()->pickerFormat();
// or statically: echo Carbon::pickerFormat();

[bjuppa]

That's interesting @weshooper!

I also see now that all the examples on the MDN input docs are without the seconds part, and it actually says "Seconds are not supported". But the MDN date and time formats docs says seconds are valid, and so does Whatwg.

If real-world datetime-local inputs works better without the seconds part, I think toDateTimeLocalString() should drop seconds and format using Y-m-d\TH:i!

I guess it's a breaking change though 😄

[kylekatarnls]

After a check I disagree this statement:

Chrome/Brave pickup the seconds and confusingly render

It's confusing only if you do not expect seconds as user input. But applications may require their user to input seconds and even milliseconds. This works fine with Chrome:

100m run start:
<input type="datetime-local" value="2018-06-12T19:25:12.324">
<br>
end:
<input type="datetime-local" value="2018-06-12T19:25:21.904">

Seconds matter (and even milliseconds could). So the user should be able to use them. And it should be explicitly removed if you don't want them.

For now it requires ->startOfMinute() call (the more explicit way).

But the improvement can be:

$date->toDatetimelocalString('minute');
$date->toDatetimelocalString('second');
$date->toDatetimelocalString('millisecond');
$date->toDatetimelocalString('microsecond');

But the default behavior would still be "second". I see no good reason to change it.

[bjuppa]

@kylekatarnls I like that improvement suggestion, letting the consumer decide what level of detail is desired! Also, not a breaking change anymore! 😎

[weshooper]

I should probably add that, by 'confusing', I mean that while Chrome/Brave renders the seconds and milliseconds, they're displayed in a faded/disabled colour and aren't selectable or editable by the user, so can't be input.

[kylekatarnls]

It can if you change the option step="1" (with a value lower than 60).

For datetime-local inputs, the value of step is given in seconds, with a scaling factor of 1000 (since the underlying numeric value is in milliseconds). The default value of step is 60, indicating 60 seconds (or 1 minute, or 60,000 milliseconds).

Source: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/datetime-local

[weshooper]

@kylekatarnls Aha, did not realise that - thanks! :-)

[bveasey]

while this works for chrome using datetime-local on ios safari the seconds cause an error. Just noting this.

[Reza1290]

This how u use it in Laravel Blade Template

$var_date = "2024-01-25 11:04:00";

in blade
{{\Carbon\Carbon::parse($var_date)->toDateTimeLocalString()}}