Answers.Body: <p>yes, agreed. Can you work on this and submit a PR for this against master (4.7). Should be a relatively easy fix. I'd probably recommend keeping Timestamp for the 4.7 cycle and mark it as deprecated and get rid of it in the 4.8 / 5.0 version</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-26T15:25:45.297Z
Answers.LastActivityDate: 2015-05-26T15:25:45.297Z
Answers.UserDisplayName: Donald Lobo
Answers.Body: <p>Note that there are 2 field types - datetime &amp; timestamp supported by mysql. Prior to 4.7 CiviCRM DAO actually blocks writes to fields declared in the xml as timestamps (this is changed in 4.7).</p>
  
  <p>Timestamp fields save the time in GMT &amp; mysql interprets the time to display based on the connection time zone.</p>
  
  <p>I don't fully understand where you are hitting the issue - but I wanted to clarify that point</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-26T23:10:38.463Z
Answers.LastActivityDate: 2015-05-26T23:10:38.463Z
Answers.UserDisplayName: eileen
Body: <p>I ran into some validation problem when run a DAO with a 'YmdHis' date string using a <strong><em>Date</em></strong> type callback. It turns out the <strong><em>Date</em></strong> type does not take a full date+time string. So I changed to use <strong><em>Timestamp</em></strong> callback with a timestamp string like this this one "1432650922" but it failed again.</p>
  
  <p>Took a look and realise that the <strong><em>Timestamp</em></strong> type is not really for Unix timestamps but for date strings in either 'YYYYMMDD' or 'YYYYMMDDHHMMSS' format.</p>
  
  <p>In this case, should we call it <strong><em>Datetime</em></strong> rather than <strong><em>Timestamp</em></strong>? Just to avoid confusions.</p>
  
Tags: <developer>
Title: Type "Timestamp" in CiviCRM
ThreadText: # Type "Timestamp" in CiviCRM
  
  (Asked by: username_0 on 2015-05-26)
  
  I ran into some validation problem when run a DAO with a 'YmdHis' date string using a ***Date*** type callback. It turns out the ***Date*** type does not take a full date+time string. So I changed to use ***Timestamp*** callback with a timestamp string like this this one "1432650922" but it failed again.
  
  Took a look and realise that the ***Timestamp*** type is not really for Unix timestamps but for date strings in either 'YYYYMMDD' or 'YYYYMMDDHHMMSS' format.
  
  In this case, should we call it ***Datetime*** rather than ***Timestamp***? Just to avoid confusions.
  
  **Tags:** developer
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2015-05-26. Score: 2
  
  yes, agreed. Can you work on this and submit a PR for this against master (4.7). Should be a relatively easy fix. I'd probably recommend keeping Timestamp for the 4.7 cycle and mark it as deprecated and get rid of it in the 4.8 / 5.0 version
  
  
  ---
  
  ### Answer by username_2 on 2015-05-26. Score: 1
  
  Note that there are 2 field types - datetime & timestamp supported by mysql. Prior to 4.7 CiviCRM DAO actually blocks writes to fields declared in the xml as timestamps (this is changed in 4.7).
  
  Timestamp fields save the time in GMT & mysql interprets the time to display based on the connection time zone.
  
  I don't fully understand where you are hitting the issue - but I wanted to clarify that point
  
  
  ---
  
  