Make submission date display formats configurable

This seems like a pretty good suggestion, though we should take it a bit further if we provide this option:

- Date and time components should also obey these settings.
- Webform uses a special function for getting variable values called webform_variable_get(). The patch should use those instead of variable_get().

I'm not sure about the strange split between export format and the normal format. The help text "Customize the date format on webform display and theming" doesn't give me a much better idea either.

Sorry for the delay in reviewing this patch. It seems like it could help solve some confusion for end users. I regularly get questions about how to change the order of date components (which uses the "short" format to determine the field order). It would be nice to eliminate that confusion and make it so that Webform could use a separate format than the normal short date.

The difference between normal format and export format is that the format for displaying dates throughout the site can be different than the format that is used when exporting submissions to a spreadsheet.

Yes I understand what the option actually does, I'm just questioning the value of it. Just about any spreadsheet application will read (an re-format) just about any date format you give it. Seems like an option that doesn't need to be there.

well, my use case was that the date was formatted as "time" without any day/month/year on the front end and I still needed to be able to export in a readable format for excel.

So I think the best thing to do here is to make multiple generic lengths and describe where they are used. i.e. a short, medium, and long format. We can map these to the site-wide short, medium, and long formats provided by core out of the box, but then users can adjust individual usages to match their desires. Short would be used for determining field order, long would be used in exports, and so on. I think right now we're already using all three lengths in various places.

At this point new features are only being added to the 4.x version, so I'm moving the version category.

So what I was thinking was that we'd want to let the user choose how each of the "short", "medium", and "long" formats are used in Webform. Right now we format dates with all three in lots of different places:

Short format:
- Determine the order of month/day/year fields when showing a date component field.
- Used in the "Table" view of the analysis for a date component.
- Used in the CSV export of a date component.
- Used in help text to describe how to enter a date for a conditional rule for a date component.
- Used to describe last date a CSV export was done.
- The submission timestamp when showing the submission list.
- The submission timestamp in the table view.
- The submission timestamp in the CSV.

Medium format:
- The submitted value of a date component in the submission page, e-mail, and token.
- The submission timestamp in the submission page.

Long format:
- The submission timestamp when viewing a submission page.

However now after having made this list, I'm not sure that letting a user set the short, medium, and long formats is really that helpful. At least in your case you needed to adjust the CSV export date size, which was previously "short", to "long". Unless you changed the short format *everywhere* to include seconds, which you probably don't want, my approach wouldn't have been very helpful.

Something that is apparent to me though is that we have two different date type everywhere: The date used by date components and the submission date. These differ significantly because a date component never has any associated time. It's always an exact day. Submission date on the other hand, the time may matter quite a bit.

So, new proposal: How about we just set an option for display of the date component, and the display of the submission timestamp, and then use one option for each?

It is definitely still present in drupal 7.

I can confirm that the issue is still present in drupal 7

I can confirm that this is still a problem in the D7 latest version.

In the emails I get 8/14/2013 instead of 14/8/2013 which basically means that I get wrong dates from most of these submissions when importing them to Google Docs here in Norway. -Although its obvious to see it on this date since we don't have 14 months in a year...

Hi @thorandre, yeah we still haven't introduced a fix. I think this patch is on the right track. Of interest, the export format problem has been mitigated by #1140026: Excel-native exporter, fixing new line and UTF-8 importing problems. We now export in Excel's native format, which stores dates/times as decimal, timezone and locale-free numbers. I've been told (but haven't tested) that upon importing Excel (and other applications) automatically will use the region-specific "short" format within that particular application. So instead of specifying a format on output, the format is defined on input to the spreadsheet program. That feature is only in the 4.x version of the module, but then again, this feature will only be added to 4.x also.

Thanks, quicksketch! That might help. I am looking forward to a stable 4.x release :) I am sure it will be even better!

If things work in the export we could change our workflow slightly to ensure we get the dates right. The problem now is that info is manually copy/pasted from emails, or even read and typed.

Yep, we still have problems regarding e-mails and even on input. The changes proposed here would still help with those problems. Right now this patch provides options for "export format" and "display format". Perhaps after these latest changes we really only need the display format for everything.

Okay, I've re-reviewed #4 and this is what we need to do to move this forward:

webform_date_format_display isn't used in the patch in #4, it should simply be removed.

+  if (function_exists('date_get_format_types')) {
+    $formatters = date_get_format_types();
+    $format_options = array();
+    foreach ($formatters as $name => $field) {
+      $format = date(variable_get('date_format_' . $name, 'D, m/d/Y - H:i'));
+      $format_options[$name] = $field['title'] . ' (' . $format . ')';
+    }
+  }
+  else {
+    $format_options = array(
+      'short' => t('Short (@s)', array('@s' => format_date(time(), 'short'))),
+      'medium' => t('Medium (@s)', array('@s' => format_date(time(), 'medium'))),
+      'long' => t('Long (@s)', array('@s' => format_date(time(), 'long'))),
+    );
+  }

The above code is intended for Drupal 6. In Drupal 7, customizable date formats are part of core, so we don't need an IF/ELSE statement in here. All core date formats should be listed, with a link to the date formats page in the description of the field.

We don't need to add a separate "export" format at this point, since we now export in Excel native formatting. This format is also used when exporting to Google Docs using Webform Google Exporter.

Rather than using this pattern all over the place :webform_date_format(webform_variable_get('webform_date_format'));, we should exclude the argument and modify webform_date_format() as such:

function webform_date_format($format = NULL) {
  $format = $format ? $format : webform_variable_get('webform_date_format');
  ...
}

+function webform_variable_get($variable, $default = NULL) {

The entire point of webform_variable_get() is to provide defaults, so doesn't make sense to introduce a $default parameter. Likewise, the one place where this new parameter is used doesn't make sense:

-    $format = webform_date_format('medium');
-    $output = format_date($timestamp, 'custom', $format, 0);
+    $format = webform_date_format(webform_variable_get('webform_date_format', 'medium'));
+    $output = date($format, $timestamp);

The special-case value of "medium" would only be used until the site-wide settings form for Webform were saved, then all formats everywhere would be the same. If we wanted to maintain two different date formats, we'd need to make a second setting. I think for our first pass at this, one universal date setting would be fine.

Is there a way to print the date (in emails, for example) in a different format using tokens?

For example, I currently print the submission data using [submission:values:date_key]... is there a way to alter the date's format by using the submission token? Is this now included in the current Webform module, or is there a patch that needs to be applied to gain this functionality?

Thanks

#18. Tokens don't have this ability.

If someone wants to take quicksketch's work in #17, reviewing #4 and put it forward to a new patch, I'd be happy to review it.

This patch:

1. Adds a webform-wide configuration option for the date format of date components. Previously this was hard-coded to the "medium" format. This may now be changed to any system format -- either a built-in one or one defined by the user via the admin UI.
2. All other administrative uses of date formatting remain hard-coded as "short". This includes downloading and reporting.
3. The submission information template (webform-submission-information.tpl.php) now uses the webform-wide configuration setting (by default "medium") rather than "long". This is a minor UI change. If you prefer "long", simply override the template file.
4. The webform date-only formats are created by stripping the system date/time formats of their time and special characters. Previously the day-of-week was stripped. Since the user can now pick whatever format they want, this is no longer done. If you are now seeing a day-of-week and don't want to, create a new type and format using the regional date/time admin UI, then set webform to use it. Or pick a medium format that doesn't have a day-of-week.
5. Webform date formats are static cached after being created. This helps speed up pages that show lots of dates, like the webform results tab.

Committed to 7.x-4.x.

Forgot one hunk. This changes the submission date token format from 'medium' to the webform site-wide format.

Committed to 7.x-4.x. Also needs port to 8.x.

@kyleheney -- Date formats are only supported for the submission date (e.g. [submission:date:long]). It would be possible, but tricky to do this for date components. The existing modifiers (withlabel, nolabel, label) make this more difficult.

If someone is interested in offering a patch or sponsorship for this, given the new ability to customize the format used by the tokens via the admin setting, please open a new issue.

Committed and pushed to 8.x-4.x. Thanks!

We are really interested in #26 "It would be possible, but tricky to do this for date components. ". I may open another ticket with sponsorship eventually; if there's already an existing solution for this that someone knows about, please advise.