add timestamp tokens (g, G, h, H, i, s, U) for hours, minutes and seconds

Very much needed for creating unique hackable URLs, or more precisely for creating more-likely-to-be unique URLs, which almost always works for a single user's site (i.e blog).

I hope this finds it way to the next release.

I searched and found this on the exact same day it was released!! What are the odds!

Is there something wrong with the curly bracket at line 14?

I get an error trying to apply the patch.

The patch in the parent is no good:

First: It has no code for the i and s specifiers (minutes and econds)

Second: the code has the date() function formatter "H" for all the different hour formats advertised

See the atached patch instead.

On a side note, adding Swatch Internet time would also be nice for the purpose of creating URLs.

Well, thanks to you, christefano, for giving me the lead. It's the first time I modified Drupal code and submitted a patch.

Regarding seconds and minutes, do you mean that you could see advertised tokens for these components in the original patch? I couldn't.

Internet time is cool if it's going to be used as part of a URL. Just as a pseudo-unique identifier to follow the date components where the the HHMMSS would have been placed, which is how I currently create nodes' paths.

Will ythis be implemented? I really miss theese tokens.

By the way, does this tokens work for comments?

Shall look into it.

But it seems to be an error in the patch

+        $values['s']              = date('s', $date);
+        $values['U']              = date('s', $date);

And

+        $values['mod-s']          = date('s', $date);
+        $values['mod-U']          = date('s', $date);

Created a patch, but it fails, could yyou help me figure out whats wrong?
I used diff -up as spesified in http://drupal.org/patch/create

I also added the entire new token_comment.inc

Also adding my own token_comment.inc, with both the last changes I mentioned and #325227: Provide e-mail and commenter homepage tokens for comments.

Attaching patch without errors.
This patch is basicly the same as in #12.
Adds g, G, h, H, i, s, U for comments, has been tested for a week now.

Added the original patch, corrected for comment 11:
http://drupal.org/node/323441#comment-1109915

I hope this can be added to -dev, so I dont need to remember to patch the file for every new update...

Tested and working, both versions.

Patch applied cleanly to token-6.x-1.11. Changing the version of the bug.

Is there any news regarding the adding of this patch to release of the module?

Dump

Here is my new editions of token_node and token_comment that reflects the patch for 6.x that is above.
I did not care for making a patch, but somebody can volunteer...

subscribe.

Also have a look at this one:
http://drupal.org/node/307520

For me the hours and minutes are more important, the refactoring can happen in a later stage.

Here's a little module for those who can't wait and don't like to patch. I hope it works.

I just noticed that the date & time tokens are replaced by dates in the time zone of the server (in my case seemingly US/Pacific), even though /admin/settings/date-time is set to another time zone (in my case Africa/Cairo), and even after I added "date.timezone =Africa/Cairo" in php.ini

The displayed node creation time on the node itself is correct, however. Only those returned by the tokens are shifted.

For example see http://ahmad.gharbeia.org/2009/08/18/183437, which token-derived URL alias has a time different than the real creation time, which is displayed on the node itself as 2009/08/19 04:34.

I think this is a critical error...

Let's see... Following great work done by donquixote, I fixed a little this module.

Now it's using format_date instead date, and comments tokens has been fixed.

Here it's.

Does anyone know the status of this and when it might be rolled into an official release? I agree with the lesergi that this is a critical fix. :)

Here's a patch for current 6.x-dev including the changes in #20.

I added AM/PM (and lowercase am/pm,) since a 12-hour clock is useless without it.

(...The list of date/time tokens could just keep growing. Could just have a [node:date-custom-????] token and allow for a php date format string...?)

I also changed the description for g, G, h, and H to "Node creation hour" instead of "Node creation time" to be consistent with the other choices. (Changed it for comment, too.)

i think #27 patch do not fix what #23 and #24 is fixing about timezone

should replace date() with format_date()

Does everyone agree that this is a critical error?

I would love to try some patches, but as I am not a developer, I don't know what errors I could look for in a patch.

I want to use time tokens for my comments in combination with the submitted_by module. In the meanwhile, I am going to experiment with the format_date api in the templates.

Feature requests are never critical.

The above furnished patches don't apply to the current 6.x-1.x-dev. They're broken in several ways.

They don't use format_date and there's no need for a 'U' format, since token already provides a 'raw' date token that is none other than the Unix timestamp.

I attach a patch for providing, hours, minutes and seconds. I tested the mods with simpletest and it passed.

I hope it can be of use for other drupalers and to the token maintainers.

Thank you,

since token already provides a 'raw' date token that is none other than the Unix timestamp.

Are you sure this applies to all 3 date formats? Date, datestamp and datetime (or how was it called)? I would imagine that "Date" "raw" is not a unix timestamp.

As seen in the code, $tokens[$token_prefix . 'raw'] = t("!description in UNIX timestamp format (1269441371)", array('!description' => $description)); is the code re-used for any date tokens. date:raw is also the same token in D7.

That's strange. It runs the tests in my dev site correctly. I don't understand the error. Is this a d.o testing setup related thing?

Attached are the test logs of the token_comment and token_node date tokens.

The images are somewhat messy, they're made with the only desktop based extension for chromium that captures all the webpage. But you can see above the stats of the tests: 0 fails in both cases. This was tested with the latest 6.x-1.x-dev version of token.

Thanks

Ok, ok. I get. It's the patch --strip option. The test bot is expecting a diff generated by a VCS. I just did it the "paleolitic" way of copying files. Ok. I'll get this in git and generate a proper diff.

Thank you,

#31: token_extra_date_tokens.patch queued for re-testing.

Subscribing

Finally set up a git repository and generated a real patch.

Here it is.

I don't get it. It works ok, the tests are passed. Isn't the patch against the current dev? Or is it against CVS HEAD?

sub

It should be against the current dev, yes, but the patch should be made from Drupal's root directory. Also, check out creating a patch from a git mirror to remove those a/b prefixes.

The "Review log" on the test details gives some indication of why things failed.

Patch in #41 re-rolled.

Thank you Jeff. Now I understand how the patch must be generated.

António,

#46: 323441-token_extra_date_tokens.patch queued for re-testing.

Here's a new version. The new dev version introduced the log related tokens and that shifted the lines a bit. That's why it failed.

I've setup a github repo for the patched version of token. Note that it's derived from token dev releases.

Here's the url: http://github.com/perusio/token.git

Patch re-rolled against latest dev.

Re-rolled.

Question: Do any of the maintainers have ideas about commiting this patch in to the dev release?

Thank you,

i find this page via google, because i can't find token for hor/minute for node cretion/moderation.

i can access $node object via php and convert UNIX dates, but token exists for simplyfication and i fink this functions must exist

please, add this tokens

Has the time zone issue as mentioned in #23 been addressed in general and standardized across all date tokens? I just ran into issues with CCK date fields and time zone conversion. Although I specified that no time zone conversion should happen, my dates are suddenly off by the time zone (the server is in Vancouver and the time zone is set to Vancouver)... Any time token that is in the morning between 0am-7am gets displayed as the day before. If I extend granularity of the date field to include hours and manually set it to 8am for example, the date gets displayed correctly.

applied #53. working. thanks.

Well I've mostly given up. I inquired twice about the patch getting in and never got a reply from the maintainer(s).

I can look into it and re-roll everything, but only if there's interest from the maintainer(s).

subscribe!

Re-rolling patch #53 by perusio.

+++ b/token.moduleundefined
@@ -476,6 +476,14 @@ function token_get_date_token_info($description, $token_prefix = '') {
+  $tokens[$token_prefix . 'a']      = t("!description am/pm (lowercase)", array('!description' => $description));
+  $tokens[$token_prefix . 'A']      = t("!description AM/PM (uppercase)", array('!description' => $description));

Can we use something more self-descriptive than 'a' or 'A'? Maybe 'ampm' and 'AMPM'?

Otherwise this looks tested. Could use some people manually testing to confirm this works for them, and as well to screenshot what the token UI looks like with the large number of additional tokens.

a and A are the format that PHP provides for this value.

See: PHP: date - Manual

Re-rolling patch #53 by perusio to current -dev, with more descriptive token names, as per #63

Token tries to use (slightly) more descriptive symbols than PHP pure (d,dd,ddd instead of j,d,D for instance)

Screenshot showing some of these new tokens being used. Sorry about some spanish-language strings in the UI.

Of course this table is several screens long, mostly due to every CCK field being there, in both -formatted and -raw options).

Patch at #65 works great for me

works great for me too. very useful tokens when you need them, thanks!