<p>You need to include a <code>timezone</code> parameter to your form in order to get the correct one.</p>

<pre><code>&lt;input type="hidden" name="postDate[timezone]" value="America/Los_Angeles"&gt;
</code></pre>

<p>If you don't include something like this in your frontend chances are high you'll receive the wrong time because it adds/subtracts a certain amount of hours. As soon as you include a valid <a href="http://php.net/manual/en/timezones.europe.php" rel="noreferrer">timezone</a> it will calculate the correct time. Otherwise it will be set to the default system timezone which may differ from your local</p>

CC BY-SA 3.0
2018-05-01T18:49:50.493Z
Thanks! That makes a lot of sense. However, I am getting an array to string conversion error. I'm not sure why, because I confirmed that I am using the same hidden input form as the same field in the back-end:

`<input type="hidden" name="fields[scriptLots][new1][fields][lotExpireDate][timezone]" value="America/Chicago">`
Steven Thate
CC BY-SA 3.0
2018-05-01T19:02:58.253Z
Did you include your `date` parameter into the array as well? `fields[scriptLots][new1][fields][lotExpireDate][date]` Can you eventually show me the file and line number of the error? Another approach is to include the timezone into the string. Here is the rule https://github.com/craftcms/cms/blob/develop/src/helpers/DateTimeHelper.php#L173
Robin Schambach
CC BY-SA 3.0
2018-05-01T19:08:45.317Z
Yep, I did add [date] to the end of the actual date input. The line that the error highlights at the top of the stack is line 171 of the file you linked to.
Steven Thate
CC BY-SA 3.0
2018-05-01T19:10:23.173Z
That means your submitted value is not an array. There must be something wrong with your HTML
Robin Schambach
CC BY-SA 3.0
2018-05-01T19:16:35.657Z
Weird. The `$_POST` dump at the bottom of the error looks correct, to my nooby eyes. Here's a full shot of the error page: https://prnt.sc/jch5gc
Steven Thate
CC BY-SA 3.0
2018-05-01T19:24:09.900Z
The issue is your `postDate` it's missing it's value and has only a timezone.. Add a valid `date` or remove the `timezone`
Robin Schambach
CC BY-SA 3.0
2018-05-01T19:24:33.483Z
Sorry... There was a second date field I didn't make the same changes to. *facepalm* It's working great now! Thanks, @robin!!
Steven Thate
CC BY-SA 3.0
2018-05-01T21:40:11.117Z
Okay, something weird is happening, sorry. Both date fields, despite what date is entered, are saving today's date. I'm at a loss.
Steven Thate
CC BY-SA 4.0
2018-05-02T04:56:06.293Z
I can't provide any help without knowing your `$_POST` parameters. All formats and syntaxes work fine on my end. But I don't rely on jquery
Robin Schambach
CC BY-SA 4.0
2018-05-02T13:45:01.620Z
Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/76891/discussion-between-steven-thate-and-robin-schambach).
Steven Thate
CC BY-SA 3.0
2018-05-01T17:27:46.597Z
2018-05-01T17:34:13.650Z
2018-05-01T17:34:13.650Z
Robin Schambach
<p>I have a front-end form with two date fields. After upgrading to Craft 3 and implementing what I believe to be all the changes concerning front-end forms in Craft 3 I am experiencing some odd behavior.</p>

<p><strong>The odd behavior</strong></p>

<p>When I enter manually or use jQuery UI Datepicker plugin to enter a desired date into any of the date fields associated with this front-end form (this is the only front-end form on the site currently), the date gets saved one day behind. E.g. if I enter 2018-05-01 it gets saved as 2018-04-30. <em>However</em>, if I go to the admin area and add a new block to this matrix field it saves correctly.</p>

<p><strong>What I changed when upgrading from Craft 2 to 3 is the following:</strong></p>

<pre><code>{{ getCsrfInput() }}
&lt;input type="hidden" name="action" value="entries/saveEntry"&gt;
</code></pre>

<p>to</p>

<pre><code>{{ csrfInput() }}
&lt;input type="hidden" name="action" value="entries/save-entry"&gt;
</code></pre>

<p>I also checked and confirmed that I am using the most up-to-date version of jQuery UI to rule out the datepicker as the culprit.</p>

<p>Here is a gist of the form: <a href="https://gist.github.com/swthate/08152aefe2c481cd792fc156a9ea1bc6" rel="nofollow noreferrer">https://gist.github.com/swthate/08152aefe2c481cd792fc156a9ea1bc6</a></p>

<p>Note: fields/inputs in question are on line 38 and line 49 of the gist (<code>lotMixDate</code> and <code>lotExpireDate</code>).</p>

<p>Thanks!</p>

<templating><datetime><frontend-form>
Date fields saving the wrong date from front-end form
# Date fields saving the wrong date from front-end form

(Asked by: username_0 on 2018-05-01)

I have a front-end form with two date fields. After upgrading to Craft 3 and implementing what I believe to be all the changes concerning front-end forms in Craft 3 I am experiencing some odd behavior.
The odd behavior
When I enter manually or use jQuery UI Datepicker plugin to enter a desired date into any of the date fields associated with this front-end form (this is the only front-end form on the site currently), the date gets saved one day behind. E.g. if I enter 2018-05-01 it gets saved as 2018-04-30. However, if I go to the admin area and add a new block to this matrix field it saves correctly.
What I changed when upgrading from Craft 2 to 3 is the following:
{{ getCsrfInput() }}


to
{{ csrfInput() }}


I also checked and confirmed that I am using the most up-to-date version of jQuery UI to rule out the datepicker as the culprit.
Here is a gist of the form: https://gist.github.com/swthate/08152aefe2c481cd792fc156a9ea1bc6
Note: fields/inputs in question are on line 38 and line 49 of the gist (lotMixDate and lotExpireDate).
Thanks!

**Tags:** templating, datetime, frontend-form

---

## 1 answers

### Answer by username_1 on 2018-05-01. Score: 5 | Accepted answer

You need to include a timezone parameter to your form in order to get the correct one.


If you don't include something like this in your frontend chances are high you'll receive the wrong time because it adds/subtracts a certain amount of hours. As soon as you include a valid timezone it will calculate the correct time. Otherwise it will be set to the default system timezone which may differ from your local

> **Comments:**
> **username_0**: Thanks! That makes a lot of sense. However, I am getting an array to string conversion error. I'm not sure why, because I confirmed that I am using the same hidden input form as the same field in the back-end:  `<input type="hidden" name="fields[scriptLots][new1][fields][lotExpireDate][timezone]" value="America/Chicago">`  
> **username_1**: Did you include your `date` parameter into the array as well? `fields[scriptLots][new1][fields][lotExpireDate][date]` Can you eventually show me the file and line number of the error? Another approach is to include the timezone into the string. Here is the rule https://github.com/craftcms/cms/blob/develop/src/helpers/DateTimeHelper.php#L173  
> **username_0**: Yep, I did add [date] to the end of the actual date input. The line that the error highlights at the top of the stack is line 171 of the file you linked to.  
> **username_1**: That means your submitted value is not an array. There must be something wrong with your HTML  
> **username_0**: Weird. The `$_POST` dump at the bottom of the error looks correct, to my nooby eyes. Here's a full shot of the error page: https://prnt.sc/jch5gc  
> **username_1**: The issue is your `postDate` it's missing it's value and has only a timezone.. Add a valid `date` or remove the `timezone`  
> **username_0**: Sorry... There was a second date field I didn't make the same changes to. *facepalm* It's working great now! Thanks, @robin!!  
> **username_0**: Okay, something weird is happening, sorry. Both date fields, despite what date is entered, are saving today's date. I'm at a loss.  
> **username_1**: I can't provide any help without knowing your `$_POST` parameters. All formats and syntaxes work fine on my end. But I don't rely on jquery  
> **username_0**: Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/76891/discussion-between-steven-thate-and-robin-schambach).  

---

