Use the tool below for various date time related tasks. Including:
- Input UNIX timestamps.
- Get the ISO 8601 string of current datetime.
- Get the mySQL date time string of current datetime.
- Get local datetime data.
- Convert between date time formats.
and more. This is powered by Day.js . The same library we use in WPEForm WordPress Form Builder.
The input is in UNIX timestamp, the number of seconds since epoch (00:00:00 UTC on 1 January 1970 ). So you don't need to worry about timezone when inputting value.
Date Time Tooling
You can change the input in Unix time stamp. It is set to current time when you opened this page.
Date Time Tooling
All date time format string from Dayjs Basic Format, Localized Format and Advanced Format are available. Escape format characters inside [<format characters>]
, like MMMM D, [at] h:mm A
.
If you want more features here, do let us know through the contact page.
How to properly store and show date time records
Developers often get confused on how to record and show date time in their applications. The followings are always the source of confusion.
- Server timezone and client timezone may not be the same.
- Storing client time with timezone is a lot of work for databases like mySQL.
- Different clients (users) may have different timezones and showing the recorded date time is often painful in such cases.
The general rule is very simple actually.
- Send only UTC date time from the client to the server.
- Store and send UTC date time from server to client.
- In client, convert that UTC date time to the client's (or user's) own timezone and display.
Just follow this simple 3 rules and your app will always work. Here's an example.
- You've created a fancy todo application, where you take task end time.
- Jenny is located in India and has entered a date time 24hrs from now, in her local time zone.
- Your application (client side) sends the date time, but only after converting it to UTC.
- Your server stores the UTC datetime in database. Probably in mySQL or mongoDB.
- When querying for todos, you send the UTC datetime to the client. Do no timezone conversion in the server. The server cannot know the client's timezone.
- Your client application (probably JavaScript) fetches the UTC date time, gets the timezone from user's browser and converts the UTC to the users time and displays it.
A win win for both you and your users.
What if my application cannot convert time to UTC
In cases where your application cannot convert the date time input to UTC then you have to figure out a way to send both user input and timezone to the server. In your server business logic, you take the input and timezone, convert the input to UTC and store.
Bottom Line: Server should always store in UTC. Client should always display in local.
This is exactly what we are doing for recording form submissions in our WPEForm application. When a user submits a form, we send the UTC datetime to the server, converted from the user. Then we show the administrator of the form the datetime in her own timezone. So everything remains consistent and relevant for the person of interest.