Where should date formatting take place in an MVC pattern?

Question

Suppose that you want to show a user list, on a web application having to handle custom date formats (depending on current selected interface language).

Several locations for applying the date format seem possible. Which one would you use, and why?

• At model, for example doing a DATE_FORMAT(user.birthdate, '%d/%m/%Y') for date fields (supposing we have a MySQL DB).

• At controller level, for example (supposing we use PHP):

  $users = UserModel::getUsers();
  // loops through results before display to format dates.
  // in the $users structure, we have to know which fields are dates or not
  $users = MagicFunctionFormattingDates($users);
  
  $view = new View('someTemplate');
  $view->assign('users', $users);
  

• At view level, for example (supposing we use a template language such as Smarty):

  {foreach key=keyitem item=row from=$users}
    <tr>
    {foreach key=keyfield item=field from=$row.fields}
       {* Here $field should be an Object or associative array
          holding its 'type' (is it a date or something else) *}
       <td>{MagicFunctionForFormatting field=$field}</td>
    {/foreach}
    </tr>
  {/endforeach}
  

A similar and related question goes for sumbitting dates (e.g. on a user registration form). Where should the date conversion take place:

• In the controller processing and validating the form, before calling the model?

• In the model?

Answer 1

I'd suggest two things:

1. The model is where your database I/O happens. In that case you want everything going in and out of the database to be a a predefined form. This is your "neutral" form, the defined interface to everything else which must always be consistent.

2. After getting 1 clear, you can do transforms somewhere else. Where else is up to your design.

HOWEVER... in thinking about this a bit more, suppose the date format changes. Suppose, further, that you allow date format to be presented according to user preferences.

In that case you would seem to have 2 choices:

1. Model: the interface is in the users preferred format. OR

2. Model: the interface is always the neutral format, in which case, VIEW should probably be where you transform to/from the way that the user gets to see it.

Going with option 2, this means that controller can also always work with the neutral format meaning that coding functions/operations in it might be easier and/or less prone to change or reworking.

However, this does all depend on what you are trying to achieve.

---

My final take on all this: keep to a neutral form as long as you possibly can and then convert to/from the user preferred form as late as you possibly can. (And this probably means View is where your transforms should take place).

Answer 2

It's really entirely up to you.

I would consider it a display detail. If you were to replace the front-end with a web service, you would want to "display" it in an entirely different way. And thus I'd put it in the view. Personally.

Answer 3

The general rule you want to convert from/to date types as close to the user as possible - really this is true of all values but especially dates.

Dates that are stored as a proper date type are unambiguous (or as close as we're going to get) as soon as you go to a string you've got all kinds of opportunities for things to go wrong. So, unless you have good reason to do otherwise (which one does from time to time), you want to convert in both directions in the UX or as close to is as possible.

If these were numbers you probably wouldn't even be asking and yet its essentially the same thing.

Answer 4

I like handling date presentation (view) and encoding (submit) at the viewer. I immediately convert it to my desired back-end date format, and stick with that format in the back-end.

One caveat - every "good" back-end system I've developed has been integrated with other systems, necessitating some amount of date conversion in the back-end, as well. I usually defer that problem to if/when these additional systems need it, and stick with the plan I noted above.

Answer 5

Several locations for applying the date format seem possible. Which one would you use, and why?

The view, because text formatting is view-related.

A similar and related question goes for submitting dates (e.g. on a user registration form). Where should the date conversion take place?

The model, via an appropriate setter method.