Answers.Body: <p>We've worked this out to handle form creation for civicrm fields in the CiviCRM entity project. <a href="https://drupal.org/project/civicrm_entity" rel="nofollow">https://drupal.org/project/civicrm_entity</a></p>
  
  <p>We use the 'type' property returned from a getfields api call like so:
  This code here we determine what widget to use:
  checkout civicrm_entity.module 
  civicrm_entity_get_field_widget()
  the section pertaining to dates:</p>
  
  <pre><code> if (isset($field_spec['type'])) {
  
          switch($field_spec['type']) {
            case 4:
              $widget = array('widget' =&gt; 'date_select','format' =&gt; 'Y:m:d');
              break;
            case 8:
              $widget = array('widget' =&gt; 'date_select','format' =&gt; 'H:i:s');
              break;
            case 12:
              $widget = array('widget' =&gt; 'date_select','format' =&gt; 'Y:m:d H:i:s');
              break;
          }
        }
  </code></pre>
  
  <p>so the '#type' of the form element is set to 'date_select' and the format is used to set the '#format' property
  this does require the date_api module from the Date project</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-10-31T20:54:41.180Z
Answers.Text: Thank you, this looks like a good workaround, but I still think this shouldn't be necessary.
Answers.UserDisplayName: Adam Hillier
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-08-20T21:59:26.343Z
Answers.LastActivityDate: 2016-08-20T21:59:26.343Z
Answers.UserDisplayName: jackrabbithanna
Body: <p>I've been working on an extension for civicrm and am using the API to retrieve fields to be used in forms presented to the end user.</p>
  
  <p>I am using the 'html.type' returned to determine which type of html form input to display (text, textarea, select, etc.).</p>
  
  <p>The first issue is that the returned values don't match up with html input types, for example:</p>
  
  <pre><code>CRM.api3('Contact', 'getfield', {
    "sequential": 1,
    "name": "birth_date",
    "action": "get"
  })
  </code></pre>
  
  <p>returns</p>
  
  <pre><code>"values": {
      "name": "birth_date",
      ...
      "html": {
          "type": "Select Date"
      }
  }
  </code></pre>
  
  <p>but <code>Select Date</code> is not an html input type. This isn't too much of a problem as long as Civi is consistent with what it calls a date field. But in the above example, the field <code>birth_date</code> expects a date without a time.</p>
  
  <p>But calling</p>
  
  <pre><code>CRM.api3('Event', 'getfield', {
    "sequential": 1,
    "name": "event_start_date",
    "action": "get"
  }
  </code></pre>
  
  <p>returns the same 'html.type' value:</p>
  
  <pre><code>"values": {
      "name": "start_date",
      ...
      "html": {
          "type": "Select Date"
      },
      ...
  }
  </code></pre>
  
  <p>and yet this field expects a datetime, not just a date.</p>
  
  <p>So if you're trying (as I am) to have an extension operate on a list of fields which can be selected by the user and so aren't known in advance, I can't see any way to differentiate between the two cases.</p>
  
  <p>I may be missing something obvious, but I can't work out what.</p>
  
Tags: <api><extension><gsoc>
Title: Inconsistency with date fields in the API
ThreadText: # Inconsistency with date fields in the API
  
  (Asked by: username_0 on 2016-07-12)
  
  I've been working on an extension for civicrm and am using the API to retrieve fields to be used in forms presented to the end user.
  
  I am using the 'html.type' returned to determine which type of html form input to display (text, textarea, select, etc.).
  
  The first issue is that the returned values don't match up with html input types, for example:
  
  ```
  CRM.api3('Contact', 'getfield', {
    "sequential": 1,
    "name": "birth_date",
    "action": "get"
  })
  
  ```
  
  returns
  
  ```
  "values": {
      "name": "birth_date",
      ...
      "html": {
          "type": "Select Date"
      }
  }
  
  ```
  
  but `Select Date` is not an html input type. This isn't too much of a problem as long as Civi is consistent with what it calls a date field. But in the above example, the field `birth_date` expects a date without a time.
  
  But calling
  
  ```
  CRM.api3('Event', 'getfield', {
    "sequential": 1,
    "name": "event_start_date",
    "action": "get"
  }
  
  ```
  
  returns the same 'html.type' value:
  
  ```
  "values": {
      "name": "start_date",
      ...
      "html": {
          "type": "Select Date"
      },
      ...
  }
  
  ```
  
  and yet this field expects a datetime, not just a date.
  
  So if you're trying (as I am) to have an extension operate on a list of fields which can be selected by the user and so aren't known in advance, I can't see any way to differentiate between the two cases.
  
  I may be missing something obvious, but I can't work out what.
  
  **Tags:** api, extension, gsoc
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2016-08-20. Score: 1
  
  We've worked this out to handle form creation for civicrm fields in the CiviCRM entity project. <https://drupal.org/project/civicrm_entity>
  
  We use the 'type' property returned from a getfields api call like so:
  This code here we determine what widget to use:
  checkout civicrm\_entity.module
  civicrm\_entity\_get\_field\_widget()
  the section pertaining to dates:
  
  ```
   if (isset($field_spec['type'])) {
  
          switch($field_spec['type']) {
            case 4:
              $widget = array('widget' => 'date_select','format' => 'Y:m:d');
              break;
            case 8:
              $widget = array('widget' => 'date_select','format' => 'H:i:s');
              break;
            case 12:
              $widget = array('widget' => 'date_select','format' => 'Y:m:d H:i:s');
              break;
          }
        }
  
  ```
  
  so the '#type' of the form element is set to 'date\_select' and the format is used to set the '#format' property
  this does require the date\_api module from the Date project
  
  > **Comments:**
  > **username_0**: Thank you, this looks like a good workaround, but I still think this shouldn't be necessary.  
  
  ---
  
  