while trying to REST POST a DateTime field with a TimeZone...
a REST POST to a DateTime Field causes Drupal to crash hard with a Database exception error and an HTTP Error Status Code 503: Temporarily Unavailable
to reproduce, setup a content type with a datetime field and post a traditional HTML TIME Format as follows:
"field_datetime":
{
"value": "2016-08-18T19:27:23-0400"
},
Note: posting a shorter format without the timezone, works, example:
"value": "2016-08-18T19:27:23"
watchdog log:
Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'field_result_bzzwrd_calc_time_value' at row 1: INSERT INTO {node__field_result_bzzwrd_calc_time} (entity_id, revision_id, bundle, delta, langcode, field_result_bzzwrd_calc_time_value) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5); Array ( [:db_insert_placeholder_0] => 93941 [:db_insert_placeholder_1] => 93941 [:db_insert_placeholder_2] => result_buzzword [:db_insert_placeholder_3] => 0 [:db_insert_placeholder_4] => en [:db_insert_placeholder_5] => 2016-08-18T19:27:23-0400 ) in Drupal\Core\Entity\Sql\SqlContentEntityStorage->saveToDedicatedTables() (line 1264 of /mnt/www/html/wabee25bjhashz8t/docroot/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).
i also tried adding:
"format" : "html_datetime"
and
"field_datetime":
{
"value": "1471566550",
"format" : "epoch"
},
...and both failed with a 422 Unprocessable Entity, which is a bit better then the 503, but still no way I can see to get a datetime value with time zone.
Comments
Comment #2
dawehnerTo be clear, producing an exception is by far not an SQL injection. There are thousands of ways to cause exceptions in Drupal, so no reasons to freak out.
The datetime module stores things explicit without timezone, as otherwise stuff like sorting doesn't work. Its using UTC as its timezone, so you can set the value as needed.
What we should IMHO do is to validate date fields, that its matching
Y-m-d\TH:i:s
exactly.PS: We are also not on twitter :P
Comment #3
mpdonadioThis isn't major, as there is a way to handle this: caller is responsible for conversion to and from UTC when using REST (see #2768651: Let TimestampItem (de)normalize to/from RFC3339 timestamps, not UNIX timestamps, for better DX).
Gracefully handling the error. @dawehner, not sure where/how we should be handling this. Do we validate in DateTimeItem::setValue() and throw an exception, or would this need to be a Constraint?
Comment #4
dawehnerGood question. I think the validation aka. a constraint would be the right level.
Comment #5
mpdonadioJust for my own notes:
And as a note, we want a constraint of Daterange, when it lands.
Comment #6
jacov CreditAttribution: jacov as a volunteer commentedwhatever we decide doing here...it would be nice to return a friendly response back to the REST service so that the { message: "incorrect date format" } or something similar.
Comment #7
Wim LeersComment #8
Wim LeersLet's merge this issue with #2768651: Let TimestampItem (de)normalize to/from RFC3339 timestamps, not UNIX timestamps, for better DX. See #2768651-8: Let TimestampItem (de)normalize to/from RFC3339 timestamps, not UNIX timestamps, for better DX and later.
Comment #9
Wim Leers