1

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 '14 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 '14 at 18:06
  • Michael Durrant, please don't edit question if you don't understand it. – Konstantin Petrukhnov Sep 30 '14 at 7:47
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 '14 at 18:03
1

Accept

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.

Storage

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

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.

Input

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 '14 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. – Michael Durrant Sep 29 '14 at 13:14
  • I Updated my answer but seems a little pedantic (no offense). – Michael Durrant Sep 29 '14 at 13:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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