A while back, I was writing a CRUD application that kept track of a “start time” and “end time” for entries that were created and stored in a database. I could subtract these time values to find a simple “length of time” for each entry. But retrieving the time data in a useful format was a bit more difficult than I expected.
Date and Time Gotchas
The hardest part of dealing with time data is the likelihood that an edge case is going to throw your application for a loop. Things like localization, 24-hour vs 12-hour time, and other topics present interesting challenges.
In my application, one difficult concept was making it possible for the user to create an entry that lasted for over 24 hours. Working within the constraints of an AM / PM format can pose a significant challenge on its own.
Setting Up the Project
This is a very basic project, and there is only minimal CSS that I won’t include here.
The HTML sets up a basic calculator outline with two datetime-local inputs.
The project looks like this so far:
1. Retrieve Time String with HTML Input
<input type=’datetime-local’> does most of the heavy lifting for localization. This will create a calendar-like input that includes a time field in either 12 or 24-hour format depending on the defaults of the user’s operating system.
2. Convert Date String into a Unix Timestamp (milliseconds since 01/01/1970)
The callback function that fires when the Calculate button is clicked is going to translate the date string associated with your time inputs into a number value.
We have created a variable that corresponds with the values of each of the input fields. We then create a new
Date object for each of these values, and pass in the values to create the date. Then, we use the
.getTime() method built into the
Date object to convert our strings into a Unix timestamp.
The reason this is awesome is that dealing with time data in the format of a string, object, or other data type is going to present significant challenges when the edge cases of your application start cropping up. If your application is configured from the ground up to accept time data exclusively in Unix format, you can easily manipulate your Unix data as necessary to display useful information to the user. We will do this in the next step.
3. Manipulate Unix Timestamp for the Front End
In the case of this project, and the CRUD application that I talked about earlier, I want to show the user the number of hours that have passed from the start time to the end time.
This comes down to a basic calculation of subtracting the Unix value of the end time by the Unix value of the start time. This will result in a difference of milliseconds that we can divide by the number of milliseconds in an hour (3,600,000). Finally, we can further clean things up by rounding to the second decimal place with
After this calculation is complete, we update the value of our “result” element to display the number of hours that have passed on the front end.
4. Adding Basic Validation
The variables within our callback function are going to represent number values based on the string that is passed to their respective
Date objects. If they are not able to do so,
NaN will be returned.
Thus, we will check to make sure neither field returns
NaN and exit the function with an
alert if either one does. We will also check to make sure that our end time is a later value than our start time.
That’s basically all that this project does, and the finished product with a calculated result will look as follows:
Applying this in Other Scenarios
The beautiful thing about working with Unix time data is how universally malleable it is. In most cases, it bypasses limitations set forth by localization, user time display preferences, and other situations that are challenging to manage.
Important Caveat about Storing Time Data
In other words, store the data in UTC, and convert the front end representation of that data to the local time of the user.
Thanks for reading.
Enjoyed this article? If so, get more similar content by subscribing to Decoded, our YouTube channel!