ISO 8601 "c" displays duplicate

This does appear to be a bug somewhere, but there is a simple and easy work-around:
Use the folloiwng string for you custom format: "Y-m-dTH:i:s"

Did you ever resolve this as I'm having the same problem as using Y-m-dTH:i:s does not produce the correct output

Y-m-d\TH:i:s\Z is the correct format for ISO 8601, 'c' format is a bastard variant that is not correct and ideally should not be used.

Hello from 2012.

Has this been resolved already?

I'm trying to implement Javascript Timer to my project, which requires ISO 8601. But i can't create a timer unless
this duplication is fixed.

PLEASE HELP!

@#4 Jeff, why would you say that “c” is a “bastard variant” when it’s listed as a valid formatting option at the Date() function’s Online Reference Manual page at PHP.net? What could be more official than that!? I saw no comments indicating any problems with nor lesser status of that format.

That said, if we must specify the format manually, it occurs to me that if timezone handling is needed, the format you gave should probably be changed to: “Y-m-d\TH:i:sP” (change “\Z” to “P”).

I, too, am trying to do this with JavaScript Timer, with no luck in Date 7.x-2.6 (with matching non-dev versions of Calendar, Views, and CTools), and also with the very latest Date 7.x-2.x-dev (with matching very latest -dev versions of Calendar, CTools, and Views). Both give the same results.

JavaScript Timer absolutely requires that the date input be in completely 100% standard unmodified-in-any-way ISO 8601 format. If anything at all is wrong in that, even the addition of a single space or stray punctuation or elimination of a digit or punctuation or anything at all, it will not work. The Date module formatting code absolutely refuses to spit out unmodified ISO 8601, no matter what I do.

I’ve tried the following in a new Display (cloned from the “Upcoming Events” Display created by Date Tools Event Calendar Wizard) for the Event Calendar View (created by said Wizard), using a sample Event that has a Start Date/Time of 2013 June 6 at 1:00 PM and an End Date/Time of same date of 4:45 PM, both in Central Daylight Time [Americas/Chicago]. The Start Date/Time should be exactly “2013-06-08T13:00:00-05:00” in proper ISO 8601. The Display is set to Show Start Date Only and show only first date of multiple-valued dates, with Repeat Rule hidden (where that’s an option):

• Date Format of either “c” or “Y-m-d\TH:i:sP” (both of which showed the proper sample output in the “Add/Edit Format” page) as Type “ISO 8601” specified, with Date Field Formatter set to “Plain” with that format
  ↑ Displays as: “2013-06-08 13:00:00 to 2013-06-08 16:45:00” ← (“to” and the End Date/Time show, even though “Start Date Only” is specified! And, neither From nor To Date/Time is in the proper format, with the required “T” and timezone string [either “Z” or “±hh:mm”])
• Same as above but with Date Field Formatter set to “Date and Time” (and Hide Repeat Rule, which is now an option) instead of “Plain”. All else is completely identical to above.
  ↑ Displays as: “2013-06-08T08:00-05:00 -05:00” ← (note that the seconds and its preceding colon are both missing [despite being hard-specified in the Date Format of “Y-m-d\TH:i:sP”] and that the timezone string [format string “P”, output: “-05:00”] is duplicated)
• The missing seconds from the above gave me this idea that this may be because I had set the Granularity to “Minutes” when setting up that Date Field. Rather than changing it and risking corruption of data in lots of existing Date Fields, I instead added a new Date Format of “Y-m-d\TH:i\:\0\0P” and set it to a new Date Style of “ISO 8601 (force :00 seconds)”, then kept the “Show Dates as” “Plain” and changed the format to the new Style in the Display
  ↑ Displays as: “2013-06-08T08:00:00-05:00 00-05:00” ← (seconds now present, but now the two forced zeroes of the seconds [but not their preceding colon, also forced] are also duplicated along with the timezone indicator!)
• Rewrite Results as “[field_date-value]” (should be raw From Date value)
  ↑ Displays as: “2013-06-08 13:00:” ← (as with the “Date and Time” version above, the “T” separator between date and time has been replaced with a space, and the “±hh:mm” timezone indicator suffix is missing entirely, and also the seconds digits are missing despite their preceding colon displaying)

Apparently there’s just no way to do this at present short of hand-coding PHP.

Actually, @razorius, turns out that both of us were doing it wrong. While this issue in Date remains, and likely will inhibit other things that would need true ISO 8601 date formats, there is a rather easy way to make JavaScript Timer work with Views involving Date Fields.

The solution is simply to enable the “jst_timer” sub-module in addition to the main “jstimer” Module. With Drush, after downloading jstimer (“drush dl jstimer --select --all”), simply do “drush en jst_timer” instead of (or in addition to) “drush en jstimer” — since jstimer is a dependency for jst_timer, enabling the latter will automatically enable the former as well. (You may also want to enable “jst_clock” for other nifty purposes.)

With that enabled, you now have a handy-dandy “Countdown” formatter right in the Views Configure Field dialog, that you can pick instead of “Date and time” or “Time ago” or “Plain”!

Note that with the latest release and -dev versions as of this writing (I highly recommend the -dev, as it gives you many more features including some preset countdown formats you can easily use and an interface for editing them and adding more), it will show countdowns for both the Start and End Dates (separated by a hard-coded “to”) and gives you no way to pick just Start. But, there’s a patch in #1507786: Date Field - Allow hiding of to date that will brute-force disable the display of End Dates entirely. A Feature Request has already been posted (same Issue queue) to request that a drop-down similar to what “Date and time” shows to select Start only, End only, or both, be added, and hopefully that’ll be added to a released version soon, but for now the patch should tide you over without needing to resort to Views PHP (as I tried to do).

I spent a lot of time to find out the same, what Joel MMCC listed in #7.
In my case I need the correct ISO output (display) for posting events to facebook (fb_autopost).

It would be helpful if this issue was solved.

Thanks!

The culprit here is the theme_date_display_single() function which concatenates the date and the timezone. For some reason, with this format the timezone is set as the same thing as the date so you get the duplicate timestamps. Haven't dug deeper into finding out why this is, but here's my less than perfect fix:

/*
 * Implements template_preprocess_date_display_single()
 */
function modulename_preprocess_date_display_single(&$variables) {
  // Fix duplicate timestamps when outputting an ISO 8601 format.
  if ($variables['dates']['format'] == 'c') {
    $variables['timezone'] = '';
  }
}

All this does is set the timezone property of the date to an empty string if the format for the date is the string 'c'. Not thoroughly tested with all use cases, but it does work for a date with a start and end time if you're outputting just the start or just the end date in a view.

I see this same issue when using just 'e' to get timezone (eg 'America/New York' displays as 'America/New York America/New York'). Took a brief look at theme_date_display_single() but appears its caller is theme_date_display_combination() which is complicated enough to avoid for a late-night quick fix.

For now, the workaround proposed in #10 works.