datetime-local html input

[dillingham]

2022-01-01T03:59:00.000000Z doesn't work in input datetime-local

db value: 2022-01-01 03:59:00

casting	value	toLocaleString()	input
datetime	2022-01-01T03:59:00.000000Z	12/31/2021, 10:59:00 PM	🚫
date:Y-m-d\TH:i:s	2022-01-01T03:59:00	1/1/2022, 3:59:00 AM	✅
none	2022-01-01 03:59:00	1/1/2022, 3:59:00 AM	🚫

🚫 <input type="datetime-local" :value="model.started_at" />

✅ <input type="datetime-local" :value="model.started_at" />

$casts = ['started_at' => `date:Y-m-d\TH:i:s` ];

Im curious what others are doing to handle basic html date input scenarios

---

Casting works but I feel like I'll need it in full ISO 8601 format for an API & match created_at etc

Currently using an jet-input vue component and v-model="form.started_at" means the date needs to be casted before.

Also casting seems to work with js Date and default doesn't? idk maybe Im wrong:

new Date(model.started_at).toLocaleString();

---

reference laravel/ideas#1940

---

[kylekatarnls]

\Carbon\Carbon::serializeUsing(function ($date) {
    if (\Request::wantsJson()) {
        return $date->toJson();
    }

    return (string) $date; // Or any ->format() / translated ->isoFormat() or ->calendar() you want
});

Would allow you to change output for view vs. JSON as you like.

But when using Vue.js, I would recommend to keep ISO 8601 string and use UTC instead local timezone for the storage as string in your JS variables.

When you'll pass those to new Date() or HTML component, the browser should convert it just fine in local timezone.

[dillingham]

hey @kylekatarnls thanks for the reply. I did some digging and looks like that serializeUsing has been deprecated and now the preferred way to do that is a method on a base model. But that was what I was looking for, thanks!

I would like to keep it ISO8601 but when I put in datetime-local and new Date only date:Y-m-d\TH:i:s works it seems

I updated the topic with more details

[kylekatarnls]

The main problem is the BE does not know the timezone unless you first send it from browser to server which is overkill in many cases. That's the reason why I deprecated serializeUsing(). Ideally you should send ISO8601 strings to any output (view, JSON) and only convert it front-side, So you keep your controller free from user timezone constraint and from the technology used front-side (you can more easily scale, plug an other view switch to an other view framework).

Then having to use new Date("20...00.0000Z") to get the local date front-side using JS sounds the correct way to localize a date with browser timezone (I think date can take the Date object without re-dumping it as string) but still this sounds not to me like a problem. On the contrary it's way more easy to new Date(model.started_at).toLocaleString() than to get the correct timezone from user and pass the local format and timezone from controller to view.

[dillingham]

@kylekatarnls thank you for the detailed answer and your work on this stuff, really helpful!

[kylekatarnls]

It is working:
new Date('2020-01-01T00:00:00.000000Z')

And if you trim it you loose the "Z" = UTC info which means your timezone is wrong.

It means the value you send does not represent the correct moment for the user timezone.

The date-time you see in your DB and the date-time the user see MUST be different because the DB one must be UTC and the user one can be in any timezone.

Taking a look at your expectations, those are actually wrong unless you also store the user timezone in DB alongside the date, else you took wrong start assertions.

What you have is not a technical issue but a logical one.

I wrote those articles that might help you rethinking it in a way that really handle localization

https://kylekatarnls.medium.com/always-use-utc-dates-and-times-8a8200ca3164
https://kylekatarnls.medium.com/handle-dates-the-right-way-in-php-c215650fc4fa

[dillingham]

@kylekatarnls yes my component was returning new Date as a computed value 🤦‍♂️

I will give those articles a read thank you, definitely something I can stand to learn more about :)

Thanks again