As you probably know already, in order to avoid awkward and confusing user experience due time zones, the input type from HTML specifications: we’re left with datetime-local, datetime has been removed where supported. Datetime Local Value A valid string for such field is YYYY-MM-DDTHH:II:SS, without the timezone info and with optional seconds, usually available on mobile devices only. It’s user timezone based The input value is not an UTC one, meaning you most likely want to save it as ISO string, which is the exact time the user meant to save compatible with your server time and zone. new Date(input.value).toISOString(); How can we store back a datetime-local value from an ISO string? If we simply remove last few chars of the ISO string, dropping the dot, the milliseconds, and the Zulu char, we’ll read the datetime as user timezone based so there will be inconsistencies. <a href="https://medium.com/media/09b793e25a75f367e707045630bdb948/href">https://medium.com/media/09b793e25a75f367e707045630bdb948/href</a> Since there is no official utility in current specifications, I’ve , which doesn’t have to be a native prototype extend, but gives you an easy way to populate an input datetime-local value. created one in a gist Once you have created a date instance from the saved ISO string, all you need to do is call the toDatetimeLocal method. input.value = new Date(ISOString).toDatetimeLocal(); The same gist contains also another little utility called fromDatetimeLocal which helps normalizing weird situations where summer time and/or time zone is returned as ISO string. To be honest, I haven’t investigated too much about this quirk behavior, and the solution might work for BST London time-zone only, but you can read in there how to normalize a date created from a non Zulu based timezone. About trusting the user agent time Once upon a time, computers and smart phones weren’t automatically updating their clock. Today, every operating system, watch, phone, wake-up alarm, is capable of connecting via WiFi or Network and automatically retrieve the right time. There are only rare cases where we cannot trust a machine datetime-local value, once converted to ISO string, and we can always counter-validate results through the server (actually, we should!). However, if you really want to be sure 100% the client has a valid date object which is synchronized with real-world UTC, you can use a similar approach I’ve used on , providingas as example , a zuluDate reference that will always have the correct time, no matter what the user do with the machine’s calendar. zulu.cloud via js Bear in mind zulu.cloud is a proof of concept, not production ready, but it works already for my personal needs and you can . find it on GitHub
