Because of the weird storage of dates, we need date.module APIs in a theme, in order to print dates nicely.

However, the most important function -to turn date-module date-strings- into real dates, date_make_date() lives in an include. It is bad practice to start including code in a theme, when all you want is manipulate the *rendering* of a date.

I suggest that these important API functions are moved into date.module itself.

Comments

KarenS’s picture

KarenS CreditAttribution: KarenS commented

You should not need to include the code in themes. To render a date you use the formatters, i.e. you call content_format('myfieldname', $myfieldvalue, 'short');

dodorama’s picture

dodorama CreditAttribution: dodorama commented

is this for datefield too?
I mean: can I use (assuming my datefield is called "data"

print content_format('field_data', $field_data[0]['value'], 'medium');

in my node-content_custom.tpl.php to format the date different (eg. in case I want a different format in teaser view) ?

Cause if I do this, the returned date is always the first day of the year.
So I don't know if I'm doing wrong or there's something weird in the function

KarenS’s picture

KarenS CreditAttribution: KarenS commented

Almost, but not quite, the value is $field_data[0], not $field_data[0]['value']. Also, be sure you have set up 'medium' in your field settings to display the way you want (it should default to your system 'medium' date settings if you haven't).

The formatters are new in cck. If you are using the latest version of the date module you will have the following options for the formatter:

default, short, medium, long - configured in your field settings
feed, ical, and iso - not user configurable, but available for formatting your date into those formats

In views, you will see an option to select the format you want in your view and you don't need to do anything else. Your node view will use your default setting unless you override it in the theme with content_format().

Bèr Kessels’s picture

Bèr Kessels CreditAttribution: Bèr Kessels commented

I don't want to use any of the preformatted, but rather one of my own strings. I could not find how to achieve that.

Bèr Kessels’s picture

Bèr Kessels CreditAttribution: Bèr Kessels commented
Status: Active » Closed (works as designed)

It is rather weird to have to choose what storage type you want by selecting a widget. But it does solve this issue, of storing the data in a usable (in PHP) format.

KarenS’s picture

KarenS CreditAttribution: KarenS commented

When you create or edit a field, you can select a format or override it with a php date format string of your own choosing. You also have the option of setting up alternate format strings for short, medium, and long. All of those options are in the collapsed fieldset called 'Advanced display options'. The idea is that you can 'discover' those options if you need more flexible formatting, but the date field will work fine if you never open that fieldset up.

Technically, you don't use the widget to define the type of database storage (timestamp or iso), that is a field choice. You use the widget to control the ui for whichever field type you use. I agree that the line between widgets and fields is murky, but I think most of us now figure widgets define the ui and most everything else belongs in the field. Widgets can be changed after a field has been defined, but the field type is integral and cannot.