Include tokens for custom date formats for date fields

I am not familiar with token module, but couldn't this be done with custom date formats???

This is working for me, though I wanted a format that didn't have a leading zero, nor uppercase AM/PM, so I used:

Index: modules/date/date/date_token.inc
===================================================================
--- modules/date/date/date_token.inc	(revision 15680)
+++ modules/date/date/date_token.inc	(working copy)
@@ -26,7 +26,9 @@
     $tokens['date']['dd']             = t("Date day (two digit, zero-padded)");
     $tokens['date']['d']              = t("Date day (one or two digit)");
     $tokens['date']['time']           = t("Time H:i");
-    
+    $tokens['date']['time12ampm']     = t("Time g:ia");
+    $tokens['date']['time12AMPM']     = t("Time h:iA");
+
     $tokens['date']['to-????']        = t("If the field has a to-date defined, the same tokens exist in the form: [to-????], where ???? is the normal token.");
 
     return $tokens;
@@ -44,7 +46,7 @@
     if (!empty($date) && $timezone_db != $timezone) {
       date_timezone_set($date, timezone_open($timezone));
     }
-        
+
     $tokens['value']          = $item['value'];
     $tokens['view']           = $item['view'];
     $tokens['timestamp']      = !empty($date) ? date_format_date($date, 'custom', 'U') : '';
@@ -62,6 +64,8 @@
     $tokens['dd']             = !empty($date) ? date_format_date($date, 'custom', 'd') : '';
     $tokens['d']              = !empty($date) ? date_format_date($date, 'custom', 'j') : '';
     $tokens['time']           = !empty($date) ? date_format_date($date, 'custom', 'H:i') : '';
+    $tokens['time12ampm']     = !empty($date) ? date_format_date($date, 'custom', 'g:ia') : '';
+    $tokens['time12AMPM']     = !empty($date) ? date_format_date($date, 'custom', 'h:iA') : '';
 
     if (!empty($item['value2'])) {
 
@@ -88,6 +92,8 @@
       $tokens['to-dd']             = !empty($date) ? date_format_date($date, 'custom', 'd') : '';
       $tokens['to-d']              = !empty($date) ? date_format_date($date, 'custom', 'j') : '';
       $tokens['to-time']           = !empty($date) ? date_format_date($date, 'custom', 'H:i') : '';
+      $tokens['to-time12ampm']     = !empty($date) ? date_format_date($date, 'custom', 'g:ia') : '';
+      $tokens['to-time12AMPM']     = !empty($date) ? date_format_date($date, 'custom', 'h:iA') : '';
 
     }
     return $tokens;

Thanks a bunch, mattyoung and jonathon_hunt.

My use of this patch is for the "submitted by" module.

I did something similar, as I wanted to be able to separate a "6:00pm" time of an event from its date in an automatically generated title (auto_nodetitle). Seeing it appear as a standard set of tokens (with the various formatting options, such as leading or not leading zeros, upper or lowercase am/pm) in the module would be great!

#4 isn't a real patch -- it's a lot easier if you attach patch files as attachments to issue comments, instead of pasting them into comment bodies like that.

Furthermore, it's confusing that time12AMPM uses 'h' for leading zeros, and 'time12ampm' uses 'g' without leading zeros.

Also, I just marked #800068: AM/PM token duplicate with this, which points to a possible solution for avoiding having to expose and maintain a million different combinations of tokens here. Instead of

time12AMPM
time12ampm
time12AMPM-leading-zeros
time12ampm-leading-zeros
...

Let's just have the following tokens:

am-pm
AM-PM
time12 (with leading zeros for now)

Then, folks can append [am-pm] or [AM-PM] as desired.

And yeah, some way to define custom tokens without changing the code would be slick. ;) Maybe in the D7 token API (which is in the 6.x-2.* branch of the contrib token module in D6) there's a better solution to this problem...

+1 subscribing

I also support this patch's concept.

I agree with #7 that it should be broken into separate tokens for the AM/PM and the time. Frankly though since there was already an attempt to have the time display without the leading zeros it seems to me to make more sense to go ahead now and add both leading and non leading zeros. If not a week after this patch is committed there will likely be another patch request to add a token without the leading zeros. Just my two cents.

Based on the above discussions I have rolled my own version of this fix and attached a patch to thisthe next post.

This patch has been tested against the current 6.x-2.x-dev and 6.x-2.4 versions, and adds the following tokens:

time12g 12-hour format hour and minute without leading zeros
time12h 12-hour format hour and minute with leading zeros
ampm Lowercase Ante meridiem and Post meridiem (am or pm)
AMPM Uppercase Ante meridiem and Post meridiem (am or pm)

It never fails... I attached the wrong .patch file... sorry.. this is the correct one...

in looking at the patch, I think the last set of tokens should have the prefix 'to-' added to them as follows

+ $tokens['to-time12g'] = !empty($date) ? date_format_date($date, 'custom', 'g:i') : '';
+ $tokens['to-time12h'] = !empty($date) ? date_format_date($date, 'custom', 'h:i') : '';
+ $tokens['to-ampm'] = !empty($date) ? date_format_date($date, 'custom', 'a') : '';
+ $tokens['to-AMPM'] = !empty($date) ? date_format_date($date, 'custom', 'A') : '';

this would make it consistent with the tokens above it and differentiate the formats from the 'from' values

You are correct. Oddly enough I have them that way in my current working copy. I must have caught that and fixed it AFTER exporting the patch last time.

I'll re-build another patch as soon as I get the chance and post it, then hopefully we can get this committed.

the patch broke stuff, and upon further testing and examination . . .

I propose these changes:
1. in the first set the description t() should be filled with commands, not description such as "with leading zeroes..."
2. I've leaned toward setting the ampm/AMPM dates to not have leading zeroes
3. I would even consider altogether eliminating the 'h' format

$tokens['date']['time12g'] = t("Time g:i");
$tokens['date']['time12h'] = t("Time h:i");
$tokens['date']['timeampm'] = t("Time g:ia");
$tokens['date']['timeAMPM'] = t("Time g:iA");

$tokens['time12g'] = !empty($date) ? date_format_date($date, 'custom', 'g:i') : '';
$tokens['time12h'] = !empty($date) ? date_format_date($date, 'custom', 'h:i') : '';
$tokens['timeampm'] = !empty($date) ? date_format_date($date, 'custom', 'g:ia') : '';
$tokens['timeAMPM'] = !empty($date) ? date_format_date($date, 'custom', 'g:iA') : '';

$tokens['to-time12g'] = !empty($date) ? date_format_date($date, 'custom', 'g:i') : '';
$tokens['to-time12h'] = !empty($date) ? date_format_date($date, 'custom', 'h:i') : '';
$tokens['to-timeampm'] = !empty($date) ? date_format_date($date, 'custom', 'g:ia') : '';
$tokens['to-timeAMPM'] = !empty($date) ? date_format_date($date, 'custom', 'g:iA') : '';

Guys, the ability to create custom date/time formats is already part of the Date module. You can set them up at admin/settings/date-time/formats/custom. You can then assign those formats to a format type, such as Long, Medium, Short, or a custom format type you create yourself.

Rather than duplicating the work of that module, I propose adding Tokens that are based on the Date module's format types. For example, the following tokens would be available:

[field-yourfieldname-long]
[field-yourfieldname-medium]
[field-yourfieldname-short]
[field-yourfieldname-yourcustomformattype]

This would make any format imaginable available to Tokens. Furthermore, we wouldn't need all of granular date tokens for every single format.

Fr0st has a great suggestion and I have taken the liberty of creating a patch that will implement this.

Unfortunately there is no clean format name aside from the description. So for the moment, at least, I used the field ID, while not as clean as a textual description, it does work.

For example:

[field_start_date-custom-42]	Custom format 'm/d/Y'

The patch is for 6.x-2.x's current build.

Thanks cap60552! I installed the lasted dev of date and applied your patch.

I'm getting the following error:

warning: Invalid argument supplied for foreach() in /sites/all/modules/date/date/date_token.inc on line 34.

Any ideas?

I am guessing you have no custom formats defined and therefor the foreach isn't being passed an array. I didn't consider that when I wrote the patch, I'll update the patch to account for that situation.

Here is the latest version of my patch, that now accounts for the condition where no custom date formats are defined.

Patch in #20 works great.

Actually, I think we can do a little better. In #16 Fr0st proposed building tokens from format types, but the patch above actually provides tokens based on date/time formats. It would probably be better if we did both: the format-types because they are the way users are used to configuring field displays, and the date/time-formats because they're more robust to configuration changes, and you don't necessarily need to map a date/time-format into a format-type.

Edit: Remove "discovery" that Fr0st had already described, and I didn't notice until after I wrote the patch.

Here's the tokens per previous suggestion.

Patch attached. This incorporates the code from #20, plus tokens for date format types, per previous screenshot.

Updated patch:
- change description of date-format tokens to be similar to Date API UI: Long date format, currently set to 'l, F j, Y - g:ia'
- date_get_format_types() always returns an array - don't check, and inline reference
- pass NULL rather than '' to date_get_format_types()

Patch in #25 works great for me. Perhaps we can finally put this one to bed?

Until today, the wildcards provided by Date module as "[field_mydate-to-????]" was incompatible with Token module validation (as performed by any well-behaving module), because it didn't support this wildcard syntax. See #376008: Can't use "to-" date tokens in pathauto. This was fixed today.

However, the new code in Token module doesn't support multiple word-elements (separated by - or _) in the wildcard, such as provided by the patch above, for example [field_mydate-to-type-medium].

Here's a patch that:
- replaces - with : for separating our elements, so we expose [field_mydate-type:format1] instead of [field_mydate-type-format1], and [field_mydate-custom:37] instead of [field_mydate-custom-37]
- removes [_-] from the type names, so we expose [field_mydate-type:longformat2] instead of [field_mydate-type-long_format_2]

This means that the following token substitution validates correctly

test/[field_mydate-custom:37]/[field_mydate-type:longformat2]/[field_mydate-to-custom:37]/[field_mydate-to-type:longformat2]

See screenshot

Bump. This is a really useful patch, especially for including date fields in Views.

Just ran the patch from #28 against 6.x-2.7 and got a hunk rejected. .rej file attached.
Something I did incorrectly or is a change in the date module causing the issue perhaps?

Using patch from #28 on 6.x-2.x dev branch working great for me. Thanks

Marking #1130844: Arbitrary custom date format tokens as a duplicate of this issue.

For D7, the issue is #906622: Cleanup the token code.

Unfortunately the D6 version of this module is no longer supported, but we appreciate the time you put into this. Per colan's comment, there was a separate issue for the D7 version.