It seems natural to me that Features should cover date formats to go along with CCK fields. Date API already sports hook_date_format_types and hook_date_formats. What's more, these hooks go into D7 so all the more reason to do it.

I would say it's just a matter of listing the date formats (and incidentally the ones that already exist in the feature). Regarding dependencies, considering for example selecting views doesn't automatically detect whichever node type is involved, we don't have to even care about the huge variety of modules that may use Date API and integrate with views. The further we could go is add detection for date-related fields and check their "default formats" for automatically packaging required formats (although this could potentially be troublesome if a load of features all provide the date format "foobar").

If no one patches, I am willing to give it a shot after my current spurt of work is over.

Comments

zhangtaihao’s picture

zhangtaihao CreditAttribution: zhangtaihao commented

It turns out to be a bit trickier than I first expected. We can export custom date format types, yes, but no flexible way to tie custom formats to them.

In short, the only way of exporting formats built using the interface is to export them separately. To link them up (i.e. to specify the "types" of a date format to be the exported types themselves), there are two options:

  1. Link the existing default format for the specified type to export. In short, the exported date format type will have but one format.
  2. Link all exported formats to a default type, either one of the exported types or a custom type namespaced to the module.

Both methods have their pros/cons:

  • The first method stays true to the type names built using the interfaces, such that any other feature already using the specified date format types retain their settings, but the type will only have one format. This is effectively exporting the format types and have the formats follow suit. Selecting formats have little meaning.
  • The second method groups exported formats by a single type. This is effectively exporting formats and ignoring format types, in contrast with the previous point. However, in cases where a particular feature requires date format presets under its own namespace, this is ideal.

I must point out that the date formats form does not allow specifying the type of a format (it will necessarily be "custom"), which means we cannot specify the relationships between format types and formats beyond the one default format.

Please feel free to add other options that you think will work and provide details so we can analyse them. Alternatively, you may like to attach a patch to describe your solution.

jayson’s picture

jayson CreditAttribution: jayson commented

I'm interested in a solution on this, has there been any progress on this?

thedavidmeister’s picture

thedavidmeister CreditAttribution: thedavidmeister commented

subscribe

jzornig’s picture

jzornig CreditAttribution: jzornig commented

subscribe THIS WOULD BE GOOD TO HAVE.

hefox’s picture

hefox CreditAttribution: hefox commented
Version: 6.x-1.x-dev » 7.x-1.x-dev

Feature requests need to go into d7 unless they're not relavent to d7

epicflux’s picture

epicflux CreditAttribution: epicflux commented

Hard-coding date formats for moving between sites can be done with a fairly simple module:

<?php

/*
 * hook_date_format_types
 */
function mymodule_date_format_types() {
  return array(
    'mymodule_date_format_day_name' => t('Day name'), 
    'mymodule_date_format_month_name_day_year' => t('Month name, Day Year'), 
    'mymodule_date_format_month_name_year' => t('Month name, Year'),
    'mymodule_date_format_month_day_year' => t('Month/Day/Year'),
    'mymodule_date_format_time' => t('Time'),
  );
}

/*
 * hook_date_formats
 */
function mymodule_date_formats() {
  $formats = array();

  // Short date formats.
  $formats[] = array(
    'type' => 'mymodule_date_format_day_name',
    'format' => 'l',
    'locales' => array(),
  );
  $formats[] = array(
    'type' => 'mymodule_date_format_month_day_year',
    'format' => 'n/j/Y',
    'locales' => array(),
  );
  $formats[] = array(
    'type' => 'mymodule_date_format_month_name_day_year',
    'format' => 'F j, Y',
    'locales' => array(),
  );
  $formats[] = array(
    'type' => 'mymodule_date_format_month_name_year',
    'format' => 'F, Y',
    'locales' => array(),
  );
  $formats[] = array(
    'type' => 'mymodule_date_format_time',
    'format' => 'g:i a',
    'locales' => array(),
  );
  return $formats;
}
?>

I haven't setup a Features 'builder' yet, but I imagine it could output something similar.

batje’s picture

batje CreditAttribution: batje commented
Status: Active » Closed (duplicate)

This is a duplicate of #1279928: Features Extra support for date_formats

thedavidmeister’s picture

thedavidmeister CreditAttribution: thedavidmeister commented

In response to epicflux's solution, this is great advice but the last piece of the puzzle is to actually select one of your formats for your format type and then push that selection into your feature using strongarm. It's a 3-step process.