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.
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.
You can change the input in Unix time stamp. It is set to current time when you opened this page.
Date Time Tooling
If you want more features here, do let us know through the contact page.
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.
A win win for both you and your users.
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.