Incorrect Date tokens

I'm seeing a similar behavior in my setup. So far, I've traced it to somewhere in the date/date.inc module. It has to do with when the date_format_date function is called to format the tokens.

I'm experiencing the same issue with:
date 5.x-1.3
autonode titles 5.x-1.x-dev
token 5.x-1.5
cck 5.x-1.3

when using date field patterns different from the one that returns the formatted date values
( i.e. if I use a pattern like: [field_date-mm] [field_date-dd] [field_date-yy] autonodetitle always display 1 Jan 2007

Auto nodetitles makes everything tricky. I'm investigating a couple of other issues with it -- some modules don't store their data in the same way during node editing (versus after it's saved), and token.module has a tough time distinguishing between the two cases. I'll have to take a closer look at it.

yes, same issue here...

cck: 5.x-1.5
date: 5.x-1.4
token: 5.x-1.6
Automatic Nodetitles: 5.x-1.x-dev

I have reproduced this as well using module versions:

auto_nodetitle-5.x-1.x-dev
date-5.x-1.4
token-5.x-1.6
cck-5.x-1.4

I think the underlying problem may be an issue with date field: http://drupal.org/node/142443

However if you want a quick fix, try changing line 257 (or thereabouts) in token_cck.inc from

      $date = date_make_date(trim($item['value']));

to

      $date = date_make_date(trim($item['value']),'none','local');

I'm not sure is this is "correct", hence I'm not submitting it as a patch. I don't know whether the timezone should be set to "none" or the the one corresponding the the date field.

@egfrith - please do provide it as a patch.

Looking at the date api - http://cvs.drupal.org/viewcvs/drupal/contributions/modules/date/date.inc... - it's not clear to me why we should need to provide 'none' for the timezone though I think the 'local' might be the ticket to making this work.

Yes, the key thing is $type='local' rather than $type='db' since as far as I can see the date_make_date() function is broken when $type='db' (which is the default). So if the date module were fixed, no changes to the code here would be necessary.

I had to provide a $timezone argument so I could set the $type (At least I think I did; PHP doesn't allow named arguments in function calls does it?).

I think any timezone would work (e.g. "GMT","none"). However, it would seem to make sense for the timezone to be the timezone that is used by the CCK date field. At the moment date_token_values() doesn't seem to get this information passed to it from content_token_values(), which in turn doesn't seem to get the information from node->$field['field_name']. Would there be a way of getting the full date object? I don't have the CCK knowledge at the moment.

If we do want to apply this as a patch, I think "none" is the correct argument, as it will return the "db" time. But do we want to apply a patch that doesn't really do the "right thing" to compensate for another module that seems to be broken?

Having said that, the patch does at least have the merit of making it explicit that we are not setting the timezone, so I'm attaching it anyway.

Well, don't know about the fix to be correct or not, but it solves the date problem. JFYI, [field_time-value] or [field_time-view] or the timestamp token were correct. Only [field_time-yyyy], month, etc. were outputting January 2007...

Applies to the dev branch. There's a similar date_make_date() usage on line 277 also, maybe that would need some care too?

I have just run into this same problem and I did some hacking once I solved the problem I found this issue.
I am doing it a little differently.

Firstly the CCK fields date format can be ether ISO or UNIX.
So to find the format I check if it’s numeric.

Secondly date_make_date() default $type is db so that is what I originally used, but then I found that date_show_date() default was local and I then needed to pass in db for each so I switch to local.
I don’t know the difference, but both seem to work as long as you pass is ‘db’ into date_show_date() if you are using db.

When it comes to the timezone, I also don’t think passing in a static ‘none’ or ‘GMT’ is correct as you can set the ckk fields timezone type to many different options including the sites local timezone. But I am not using timezones so I don’t know if a 3rd value is added to the object.

When it comes to the second to value, I am not to sure and I have not tested that yet as I at this time don’t have a field with a to date.
But it looks wrong. It check if $item['value2'] is not empty then after that it uses value without the 2.

I will try to look at this more later when I have cck fields that use timezones and to dates. But for the moment I think this is a small improvement on egfrith patch.

Not only incorrect date tokens, but you also get incorrect page titles , using the date as the argument (%1 etc). You also get incorrect summary links if you use the CCK date as an argument in views when using "Summary" and "day" as the option.

I don't understand why the CCK Date makes you choose no timezone handling if you don't want to use hours granularity?

I think we should reopen this to get a fix in the real problem itself, the date module.

yes, same exact issue here but with pathauto...

cck: 5.x-1.6-1
date: 5.x-1.6
token: 5.x-1.8
pathauto: 5.x-2.x-dev

Why doesn't this module use code similar to how date_pathauto.inc does it from the date module, since extracting the parts of a date field worked in pathauto before it went to using tokens. Here is the code from it date_pathauto.inc 5.x-1.6:

        if ($field['type'] == 'date' || $field['type'] == 'datestamp' && is_array($field['granularity'])) {
          // this could probably be done better
          $fieldname = $field['field_name'];
          $datefield = $node->$fieldname;
          $datevalue = $datefield[0]['value'];
          // from date.module
          if ($field['tz_handling'] == 'none') {
            // if no timezone handling was elected, create a date object with the database value
            $date = date_make_date(trim($datevalue), 'none', 'local', $field['type']);
          }
          else {
            // create a date object with a gmt timezone from the database value
            $date = date_make_date(trim($datevalue), 'GMT', 'db', $field['type']);
            // convert the date object to the proper timezone, depending on the field's tz_handling value
            date_convert_timezone($date, 'GMT', date_get_timezone($field['tz_handling'], $item['timezone']), 'local');
          }
          $iso = $date->local->iso;
          if (is_array($field['granularity'])) {
            // we were using the date_iso_field calls, but we'd prefer 01 rather than 1 for january
            if (array_key_exists('Y', $field['granularity'])) {
              $results['['. $field['field_name'] . '_y]'] = pathauto_cleanstring(substr($iso, 0, 4));
            }
            if (array_key_exists('M', $field['granularity'])) {
              $results['['. $field['field_name'] . '_m]'] = pathauto_cleanstring(substr($iso, 5, 2));
            }
            if (array_key_exists('D', $field['granularity'])) {
              $results['['. $field['field_name'] . '_d]'] = pathauto_cleanstring(substr($iso, 8, 2));
            }
            if (array_key_exists('H', $field['granularity'])) {
              $results['['. $field['field_name'] . '_h]'] = pathauto_cleanstring(substr($iso, 11, 2));
            }
            if (array_key_exists('N', $field['granularity'])) {
              $results['['. $field['field_name'] . '_n]'] = pathauto_cleanstring(substr($iso, 14, 2));
            }
            if (array_key_exists('S', $field['granularity'])) {
              $results['['. $field['field_name'] . '_s]'] = pathauto_cleanstring(substr($iso, 17, 2));
            }
          }
        }

@therainmakor - please provide your ideas as a patch. http://drupal.org/patch/create

@devendra.ishaya please don't arbitrarily change the status.

Just as an FYI, I opened http://drupal.org/node/170044 recently, but someone pointed out that it pretty much duplicates this one. I'll mark that one as duplicate. This problem is affecting me and someone else.

Well, this is "patch (code needs review)" so if you are bitten by this bug can you test the patch?

NaX's May 30 patch appears to work for me.

Same patch works for me, too.

NaX's patch works for me, too

This patch works for me on the latest dev item of token; pls apply!

Ok, I applied this to 5.x-dev so it now needs to be ported to the 6.x branch.

Did this make it into Token 1.9? If not, what is the hold up?

@Aren Cambre - my comment and the status change in #24 signifies that this has been applied to the 5.x branch. If you look at the affected file token_cck.inc and because I follow Drupal standard commit messages you can see that in the 1.1.2.8 revision of that file I applied this patch. Then you can see that one revision later I marked the file for the 5.x-1.9 release node and have created that release.

So, yes, it's released. It's waiting to be ported to the HEAD branch which is the precursor to 6.x-1.x.

If you experience this problem after upgrading to 5.x-1.9 then perhaps we need to revisit the issue. Please create a new issue and detail what steps you took, what the expected behavior was, and what the actual behavior was.

Maybe I misunderstand something, but if it's in 1.9, why is this big report not closed?

because it needs to be ported to Drupal 6.x, per the status tag

Oops, thanks.

Ported in eaton's work this past weekend.