Date tokens returning earlier date

This code is in date module now.

I'm posting a patch here for review. I was having trouble with Date tokens as well, and it came down to two issues. (both of which are in this patch)

1) The initial date tokens (From date) were actually getting set from "value2" (To date) rather then "value" (From date). Easy fix there :)

2) Timezone changes were getting applied when they shouldn't be IMO. For example, I have a Date field that only allows dates, like /mm/dd/yyyy. No times. Therefore timezone settings are not applicable and can't be set for the field. The system default timezone setting for the server is US Mountain Time. When token was running it would take the date and run a conversion from a default UTC timezone to US Mountain, time which brings it back to the previous day.

I think the correct behavior would be to ignore timezones if information isn't present?

There are a couple bug reports related to this issue that I'll try to mark as dups here..

Thanks!

I've just applied this patch to Date module version 6.x-2.0-rc4 and it doesn't seem to have worked, it is still providing a token in my case that is a day behind what the actual date is supposed to be (as in http://drupal.org/node/311303). Is this because the patch is meant for a different version? This issue is set for 6.x-2.x-dev, but the latest release is rc4 at this point. What version is the patch meant for, and does it matter?

Well it was patched against the latest dev version available when I posted, which is newer then RC4, although I don't think there were changes to the token file. (The dev releases are the releases in red on the project page http://drupal.org/project/date)

But really from the description of your problem on the other thread, I would think that this patch should work for you. :/

Did it apply cleanly? There are only two lines it changes in date/date_token.inc, so you may want to just verify them by hand.

Patch worked for me. The easy fix from "value2" to "value" indeed did the trick.

I'm having what appears to be the same problem in Date 5.x-2.3. My automatic node titles (set to Month YYYY) are one month behind. If the patch works, can it be back-ported?

(If this should be a separate issue, let me know and I'll create it.)

This patch worked for me as well. I use date tokens in automatically generated URL aliases but instead of the field data the current date was used (at the time when the alias was generated). The issue was resolved by applying this patch. Thanks a lot!

I too was having a problem with the date argument supplied to the page URL by Views - it was offsetting the date by one day for some reason. Anyway, without understanding everything that's said here, I applied the patch to the latest dev version as of today, and now the auto-generated URLs look fine now. Thanks for the patch. :)

This patch fixes my auto_nodetitle problem as well.

As this is working for several who have tried it, I'm setting it as "reviewed and tested". Karen if you have a chance maybe you can see if I was on the right track?

Thanks!

Sorry to be so slow getting to this. The first proposed fix is totally correct, 'value2' should be 'value'. I just committed that fix.

The second is a problem. I'm sending the correct db timezone in the item so that it shouldn't have to use the fallback at all, so the problem is that the item isn't getting the right information and I need to keep an eye on this and try to figure out why. The default db timezone is 'UTC' for most dates, dates without timezones are the exception, not the rule.

So marking this CNW until we figure out why the right timezone info isn't getting to the token.

I finally found the real source of the problem. I was adding the needed values in date_load() but those values were getting stripped out again before they got back to the token handling. This affected both the D5 and D6 versions, so I've made a fix to both.

I am having the same issue where I would select day '6' and my token value would then show day '5' instead, always one day off. The case where the token is not working correctly is with using the auto_nodetitle module but that module simply passes the $node object to token_replace so it's got to be an issue somewhere else other than inside of the module auto_nodetitle.

I have noticed by putting the following inside the date_token_values function that it gets called twice for me. The first time it outputs '5' and the second time it outputs '6':

<?php
dpm($tokens['d']);
?>

The first item sent to date_token_values does not have the db timezone set and is the item returning the improper day. The second item contains the db timezone and returns the proper day. My temp fix was to set the sites date/time configuration to use UTC as the default time zone, this was a working remedy for me but is problematic for sites that have a need for setting a default timezone other that UTC.

This is happening in 2.1. Since 2.1 has a release past the most recent comment on this issue, I converted this issue to version 2.1.

With 2.1, the token [field_FIELDNAME-month] returns the prior month. E.g., if it should return April, it's actually returning March.

I've been experiencing this issue in the 5.x-2.x branch. I did some debugging today, and the issue seems to be related to the timezone_db variable.

Putting the following in the _date_token_values function in date_token.inc outputs the contents of the $item() array.

dpm($item);

On my site, this is the result.

Array
(
    [value] => 2009-04-24T00:00:00
    [value2] => 2009-04-26T00:00:00
    [timezone] => America/New_York
    [offset] => -14400
    [offset2] => -14400
    [view] => <span class="date-display-start">04/24/2009</span><span class="date-display-separator"> &#8211; </span><span class="date-display-end">04/26/2009</span>
)

Note that [timezone_db] is missing from the output. This means that on line 43, $timezone_db is always set to UTC.

    $timezone_db = !empty($item['timezone_db']) ? $item['timezone_db'] : 'UTC';

If I look at the Dev Render tab for this node, [timezone_db] is there.

Array
(
    [0] => Array
        (
            [value] => 2009-04-24T00:00:00
            [value2] => 2009-04-26T00:00:00
            [timezone] => America/New_York
            [timezone_db] => America/New_York
            [date_type] => date
            [view] => <span class="date-display-start">04/24/2009</span><span class="date-display-separator"> &#8211; </span><span class="date-display-end">04/26/2009</span>
        )

)

So, at some point, [timezone_db] is either getting stripped out of the $item() array, or isn't being added in the first place.

As a test, since my [timezone] and [timezone_db] are identical, I manually set $timezone_db = $timezone. This resulted in nodes with the correct dates in the title, proving that the issue is the missing [timezone_db] value.

I have now hit a wall. I can see that $item comes from the $object parameter of the function, but where does that $object parameter come from? Can [timezone_db] be added to that parameter so that the date tokens function correctly?

We're still experiencing this problem with the latest -devs, but we also notice it's only occurring with tokens handled by auto_nodetitle and not by pathauto.

That is, we have a Date field for month and year; submitting 2009 September produces the correct pathauto, "200909," but the incorrect/decremented auto_nodetitle, "August 2009." The error might thus lie with Token or Auto_nodetitle.

One major difference between Pathauto and Autonodetitle (and a reason why this may be present) is that Pathauto has a weight of 10 in the system table meaning that it runs relatively late in the node creation process. Autonodetitle, as far as I know, runs a bit earlier.

Hmm, to be precise, Auto Nodetitle will run before Date and Pathauto after (unless Auto Nodetitle has set a higher system weight). This may indeed be important. The Date module provides timezone information during node_load() that is used in the token transformation, so it may be that the timezone information is missing when Auto Nodetitle handles the information, but correct by the time Pathauto does.

If that is the problem, it could be fixed by giving Auto Nodetitle a higher system weight. If someone experiencing this could test that to be sure, this could be moved to the Auto Nodetitle issue queue. If you make any such changes, you need to clear cache_content before testing because the CCK node_load() only happens if the cache is empty.

I'd be happy to test, but can someone give hints on what needs to be hacked to do this?

Just change the weight in the system table for the auto nodetitle module to some high number to force it last.

Actually, on our installation, token had the highest weight of all, and auto_nodetitle was already executing after date:

date: 1
pathauto:1
auto_nodetitle: 5
token: 10

Changing auto_nodetitle weight to 15 (then clearing caches and reloading the modules page) did not change the results; "February 2010" is still translated to 201002 by pathauto and "January 2010" by auto_nodetitle. For giggles I changed it to 0, and then tried setting token to 3, neither of which had any effect.

I think auto node title works in a different part of the hook_nodeapi and/or node form submission process, so the weight may not matter because it's different.

test with Drupal 6.10 - the patch in #3 fixed the pathauto token "one day off" issue but not the autonodetitle token "one day off" issue.

Reported in the auto_nodetitle queue at #460532: Auto Nodetitle generates wrong date parts.

Subscribing

It looks like a portion of the patch from #3 has made it into the latest release of the date module, but without changing the UTC line it still does not work as expected.

The patch no longer works with the latest release.

Line 42 of the latest release reads:

$timezone_db = !empty($item['timezone_db']) ? $item['timezone_db'] : 'UTC';

and to work properly needs to be changed to:

$timezone_db = !empty($item['timezone_db']) ? $item['timezone_db'] : date_default_timezone_name();

autonodetitle token "one day off" issue occurs for me also, with latest drupal and module.

I ran into this issue this morning. I can't speak to the ramifications of changing this line, but here's a one-line patch from #35 against the 2009-Jul-25 release of 6.x-dev; it fixes the problem for me.

Patch in #37 works well for me. I see no reason why UTC should be used instead of the default timezone. And this is the only thing this patch changes. Please commit this patch.

I can verify that this fixed my issue with auto_nodetitles

This patch will fix some people's problems but break others. Most dates use a db timezone of UTC, that is why it is the default. The people experiencing this must be using dates that are not stored in UTC, at least that's what I'm guessing. The granularity of the date field and its timezone storage method affect this and possibly the type of datefield has an effect. I have to figure out why the right timezone is not getting passed in, changing the default value will just fix one problem and create another.

Hi
could you please share more insight on this issue.
You say that the timezone of the database field affects the casting inside of php? I can't see how could this be a problem as I can't find casting done from the database inside this module? Is CCK Casting the date?

[Edit]
Sorry I have to look into this some more...

Suscribing.

This may be obvious, but in case it helps...

As noted above, date_token_values seems to get called twice. AFAICT, the first time a complete date object gets passed in, and correct values are returned. The second time the date object that is passed in (as stored in $item) seems to be missing the following elements:

[date_type] => date
[timezone_db] => America/New_York

Could some of the manipulations done in token module be losing that data?

This continues to be an issue, and I'm having a hard time remembering to apply the patch or manually change the UTC default to the default site timezone each time there is an update, until I post new content and see that it's been titled incorrectly. Having a large amount of content that has dates in the auto generated titles, this is a major usability issue for myself and my users.

If the reason the patches supplied here have not been implemented is that some people store dates as UTC and some do not, perhaps the best solution would be to add a site variable that can be read to determine whether dates are stored in UTC or local/site timezone. That way once it's set, it should never change and future updates should be seamless as expected.

Seems to me that would eliminate this issue without breaking anybody's site. I don't have time to create a patch to add this functionality at the moment, but it should be pretty straightforward to implement.

Finally. This did cost me a lot of time:

The CCK Field doesn't provide all data we need in the token call from auto_nodetitle. The reason for this is the operation for the field that is used which is "presave". If I add this just like "insert" and "update" everything runs fine. The timezone used was never the issue there. It just was never submitted. Because of this the patch from before did work but now I see why it never was a real solution.

I tested #44 in 6.x-2.4 against what I assume is a related bug (a token supplied date/time field returns a value not adjusted for the site timezone when using rules / rules scheduler). The patch did not resolve the problem on my dev site.

Setting this to needs work again than.

Can you tell me anything about your setup so I might be able to test this behaviour?

I am setting this to "Needs review" again. I double checked the usage of _content_field_invoke in my project with the netbeans IDE and I am quiet sure that any module that uses a date cck field will go through the date_field function and get the fields added. If you can't any details why this patch can't work it still needs a detailed review.

Alright, I created a simpler test case using rules and it works as expected. My previous test was trying to use a datetime field to schedule a rule to run in the future and had another issue that was preventing it from working. Setting this back to needs review. Sorry for the confusion!

edit: walked away while writing my response and missed the previous comment.

I am also seeing this issue. I will test the patch later...

Subscribing

I tested the patch in #44 and it worked perfectly. Specifically, it fixed the issue where Automatic Nodetitles would show one day earlier.

Patch #44 worked well for me too. I had the same problem as will_in_wi from comment #55.

To confirm circumstances: I have a date field with no timezone conversion and only year for granularity that I'm trying to use in creating a title with auto_nodetitle, but it's showing as one year too early with the [X-yyyy-value] token. This same token works fine for pathauto.

I currently have the patches in both #3/#37 and #44 applied, but no change.

So far, I've entended granularity to include everything Year, Month, Day, Hour (just to check): No effect.
Keeping this granularity, I switched to site timezone (since you need at least hour for this setting to be allowed): STARTED WORKING
Tried UTC, and auto_nodetitle still kept working.
Switched back to no timezone, and auto-nodetitle started displaying the year incorrectly again.

So I guess the temporary fix is just to add some sort of timezone handling, and increase the granularity to allow that.

Hopefully this helps someone else! Not sure how important the patches were to the solution, so just add them all -- they're quick and easy :)

Rock on, compadres

Hmmm... and I think this might just be how tokens work, but if you load your node edit form (the one with auto_nodetitles), THEN switch the timezone handling (in another tab), then resave your node back in the first tab, the nodetitle will still be incorrect... It might have had something to do with the fact that the field it was pulling title info from didn't change values (was "2009" when loaded, and saved with "2009"), so maybe it's a resource-saving measure to keep tokens from being refreshed for no reason.

Anyhow, just a heads up on it :)

@biocomp.pat
Please do not use all patches together!
They are totally different approaches to the issue and I think that only the one in #44 is the correct fix. The others before might even mess this up.

And I first thought that using the time zone handling is a fix. If I recall it right the function that should handle the field settings was not fully implemented and always defaults to UTC or the default. So this might work for you but not necessarily for all.

#44 just adds the time zone handling to one additional CCK action type and by this Token can use the full data.

Thanks Kars-T! I'll remove the other fixes later today and come back to mention whether my issue reverted.

Ah, you're right: reverting the #37 patch still kept my work-around working. I owe you one kswan

The patch in #44 did the trick for me.

Is this ready to be committed?

As per patch #44, I added the presave case to the code at the appropriate place in 6.x-2.4 (because I didn't want to use the dev version on my production site), and it solved the auto node titles problem for me.

The patch in #44 works for me (using auto node title). Here's a reroll against the latest.

Unassigning it. This patch again does the trick. Just applied it to another install I have. Would love to get this committed.

Marked #671740: Date 1 Day Off as a duplicate thread.

Confirmed patch in #60 works for us...same issue with automatic node titles based on CCK date field are off by 1.

Patch in #60 works for me, too. Automatic node titles work splendidly after applying. Can we get this committed?

Patch #60 also worked for me.

Finally got this committed. Thanks for all the debugging work.

Wahooo!! thanks KarenS

Many thanks Karen! :D

When using a date token for the number of the day, it is off by one.

If the date stored is May 24, 2010 I receive a 23 instead of a 24.

Your tracker shows you as really active, so apologies if this is insulting, but are you working with most recent dev? It's always good to toss that out there when you reopen a closed issue, since it's a common misunderstanding :)

Cheers

That's a good question and I should have mentioned it. Thx Patrick for bringing that up.

I'm using Date 6.x-2.4 and Drupal 6.17, which are the most current releases as of this posting.

I did some further testing on this issue and I believe the problem is that "No Time Zone Conversion" was being used on the field type.

I created a copy of the field but with "Site's time zone" selected as the time zone handling and the correct number was output by the date token for that field.

Sorry! I wasn't quite clear on how the dates are stored but this was quite helpful: Date Locale & Time Zone configuration settings

For anyone who might be confused with timezones, I thought this might be helpful too...

I'm in the America/LosAngeles time zone which is normally UTC-8, currently UTC-7 due to daylight savings time.

For both datetime fields, I was using the pop-up calendar and only setting month-day-year. Note that when creating the content I set the date for June 2, 2010.

I printed out the day and time of both fields using date tokens in "Automatic title generation" and received the following...

field entered with no time zone conversion:
01 17:00

field entered with time zone conversion:
02 00:00

Looking inside the datebase, the datetime values were stored as...

field entered with no time zone conversion:
2010-06-02 00:00:00

field entered with time zone conversion:
2010-06-02 07:00:00

So looks like time values stored in the database are in UTC.

When you retrieve this data, drupal will convert for your time zone setting which for me is -7. Thus Apr 2 2010 00:00 - 7:00 = April 1 2010 17:00 for the field entered with no time zone conversion.

I think this is correct. Hope this is helpful to someone... maybe just me :)

I'll go ahead and set the status back to closed.

Sorry to drag this on but I took another look at Date Locale & Time Zone configuration settings and it seems that my findings actually contradict the second sentence of what is stated in time zone handling rule #5 shown here:

5. No time zone conversion - The date entered is not converted when saved to the database. When retrieved from the database, the data is NOT converted and is displayed exactly as entered.

When retrieved from the database, the data is clearly being converted!

I am assuming that using the date popup calendar where I only enter day-month-year where I select June 2, 2010 - I am storing: 2010-06-02 00:00:00

Please note that my site's location is set to America/LosAngeles which currently happens to be UTC-7.

For completeness I've added a datetime token for each field to my output from Automatic Nodetitles, retested and presenting data here below:

0. Site setup/settings:
- using Drupal 6.17
- using Date 6.x-2.4, Token 6.x-1.13, Calendar 6.x-2.2, CCK 6.x-3.x-dev (2010-Jun-18), Automatic Nodetitles 6.x-1.2
- user-configurable time zones: disabled

1. field with NO time zone handling - "Time zone handling" for the field has been set to "No time zone conversion"

2. field WITH time zone handling - "Time zone handling" for the field has been set to "Site's time zone"

3. date entered with popup calendar for each field:
June 2, 2010

4. date shown in database for field with NO time zone conversion selected:
2010-06-02 00:00:00

5. date shown in database for field WITH time zone conversion selected:
2010-06-02 07:00:00

6. date shown in output using datetime token for field with NO time zone conversion selected:
2010-06-01T17:00:00

7. date shown in output using datetime token for field WITH time zone conversion selected:
2010-06-02T00:00:00

So in item "6." shown above - according to Rule #5 we should have received a 2010-06-02T00:00:00, but that is not the case.

Looks like on output timezone conversion is happening regardless of the requested time zone handling.

Or am I missing something?

I hope I'm not being a pest, but because of this contradiction I'll set the status back to active and hopefully someone can clarify the situation.

You need to use the development version. The patch isn't in 2.4

6.x-2.4 released way back in Sept 2009, and Karen didn't commit the patch until Apr 13 2010. I get the impression you just misread the year and I totally feel you pain -- I've done the same.

Whenever you find an old solved issue, it's always good to flip back to the project page and make sure the fix has made it into a stable release.

Maybe your issue will still be legit after installing dev, but I'm just going to close this for now so that the exchange doesn't show up in everyone's issue queue. Cheers!

(Props on the in-depth sleuthing regardless :)

Thank you Adam and Patrick for your feedback and comments. Sorry about my confusion - hope I didn't take up too much of your time! And thank you Patrick for the good advice. Much appreciated.

I'm using Date 7.x-2.0-alpha4 and this problem is occurring. Was the fix applied to the 7.x-2.0 branch?

This issue was for 6.x-2.x, which is completely different from 7.x-2.x.

See this issue for date field token support in 7.x-2.x:
#1103032: Document how to use date tokens

Not to exhume a dead horse, but does it bother anyone besides me that the patch in #60 makes for duplicate nodeapi processing when saving? Once on presave and again on insert/update? I was debugging a different issue and noticed this was happening.

Seems like there should be a more elegant solution for this. Why is it invoked twice?