Different systems accepts different formats of formating time. E.g.

  • java, jquery: yyyy-MM-dd HH:mm
  • some jquery plugins: yy-mm-dd HH:MM
  • momentjs: YYYY-MM-DD HH:mm
  • ISO-8601: YYYY-MM-DD hh:mm
  • etc

On server I store time as Epoch time. And like to store some timeformat for user, so he see same format everywhere. But I just can't save and pass format string as it will be used differently. I saw various solutions, like restricting choice to 3-5 predefined options, and having list of these options in every system.

How to store time format and show formatted time-date to user in cost-effective way?

---- Example ----

I store time on server as 1412063513 value. In browser user want to see it as 2014-09-30 10:51. So he provide desired timeformat as 'YYYY-MM-DD HH:mm'. I save that format to server, but if i need to use it on server side (java) I got problems, as it is not valid due to capitalized letters. And when other systems trying to query data and format it, same problem arise.

  • 3
    Umm, pick one format-format for your backend, and translate it to the required format for each formatting frontend. In the cases you've shown, this is a matter of simple letter substitutions.
    – amon
    Sep 29, 2014 at 9:53
  • If I understand what Amon wrote then that's the best answer. Your application should only use ONE date format. If you are using different libraries/presentation formats then immediately prior to making the call (or after reading the time from the other format) is when the conversion takes place. You do not want different timeDate formats floating around in your application unless you like tracking down obscure bugs.
    – Dunk
    Sep 29, 2014 at 18:06
  • Michael Durrant, please don't edit question if you don't understand it. Sep 30, 2014 at 7:47

2 Answers 2


The more formats you support the more problems that will inevitably arise when dealing with datetime formats.

If you intend to validate the inbound value then (I'm sure I'm stating the obvious here but) I wouldn't recommend trying to create your own process to do this, as its often a minefield of problems. DateTime object in PHP is a good at handling a variety of input date formats simply, allowing you to validate and define the output format, therefore allowing you to store the value in a single format, as anom suggests in his comments above. momentjs.com also has similar capabilities. I'm sure lots of others also exist!

If you need to display the date-time again in the original format in which it was received, the only option I can see would be to identify the inbound format in the first place, store this format alongside the original value, and then use the DateTime object format method again using the stored format when building the output content.

Personally I would question carefully if users really need to see the output date in the original format. A standard format would be more consistent and much less of a headache for you in the long term dealing with new formats and bugs etc.

  • 2
    Yes, definitely use built-in functionality and do not reinvent the wheel. Otherwise, your code just might end up on The Daily WTF,
    – user22815
    Sep 29, 2014 at 18:03


There is no single or simple answer to this issue (I've been dealing with it for 30 years...) and your local solution will just depend on the technology, locale and tools that you have.


Use a storage mechanism that support date and datetime data types. This will save you from re-inventing the wheel when it comes to validations and will provide you with a consistent internal storage and format you can rely on. This will mean that in your storage you have addressed different date format by choosing one.


Display according to local preferences and consider using the users locale to determine the format. You will need to use a format that is accepted by either the users or the language or library(s) being used.


Use a variety of mechanisms to tell the user the format they should use, including instructions, labels, input field autoprompt text, etc. Consider using a 'word' for the month so that you can avoid, for example, the 12-01-2014 or 01-12-2014 issue (in the UK Dec 1st is 1/12, in the US it is 12/1) by using formats with month, e.g. dd-mon-yyyy which would use 01-dec-2014 for December 1st This addresses the problems of different format in different libraries by defining the format to use.

  • 1
    I think the problem is not about obtaining, storing, and displaying dates, but about bridging the different date format languages used by various languages and libraries involved in OP's site. to format a date like 2014-09-29, one language might need the format string "%y-%m-%d" while another might require "YYYY-MM-DD". One proposed solution was manually translating a limited number of formats to each system, so that an identifier like format 1 would be used to look up the format string, but that doesn't scale and doesn't allow for user-defined formats.
    – amon
    Sep 29, 2014 at 12:16
  • I have found that the problem with different date formats comes when you are trying to store, display and validate the date. Sep 29, 2014 at 13:14
  • I Updated my answer but seems a little pedantic (no offense). Sep 29, 2014 at 13:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.