Using the input datetime-local
As you probably know already, in order to avoid awkward and confusing user experience due time zones, the input type datetime has been removed from HTML specifications: we’re left with datetime-local, 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.
Since there is no official utility in current specifications, I’ve created one in a gist, which doesn’t have to be a native prototype extend, but gives you an easy way to populate an input datetime-local value.
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 zulu.cloud, providingas as example via js, a zuluDate reference that will always have the correct time, no matter what the user do with the machine’s calendar.
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.
Hacker Noon is how hackers start their afternoons. We’re a part of the @AMI family. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.
If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!
