Answers.Body: <p>The main clue is that these date/times are being stored in mysql datetime fields, which do not include a timezone, but implicitly have a server-wide timezone (either adopted from the server, or configured explicitly).</p>
  
  <p>So we know that the problem is at the php level - the code is generating the date time and converting based on the current user's timezone (which it shouldn't in this case).</p>
  
  <p>Since it's an issue with D8 and not for D7, it seems likely that it's a D8 integration issue, some kind of automated handling of date/times that we don't want (we do want date/times to be converted to the users timezone on display).</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-10-31T14:09:38.283Z
Answers.LastActivityDate: 2019-10-31T14:09:38.283Z
Answers.UserDisplayName: Alan Dixon
Body: <p>When I'm logged in -> and make a Contribution at 4:20pm - all is well!</p>
  
  <p>I log out and then make a Contribution through the exact same Contribution page and notice that the Contribution clocks in at 10:24pm (so +6h - that's UTC I think as I believe the UK did their timezone change last weekend);</p>
  
  <p>Any clues as to what may be going on here?
  This is on Drupal 8 / CiviCRM 5.15.1 </p>
  
  <p>My default time zone in Drupal is set to Edmonton [Canada]. The 4:20pm was correct.</p>
  
  <p><a href="https://i.sstatic.net/m9vn4.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/m9vn4.png" alt="enter image description here"></a></p>
  
  <p><strong>Additional Info:</strong></p>
  
  <ul>
  <li>CentOS thinks it's ET (+2h) - which is fine [machine is in Montreal]; </li>
  </ul>
  
  <p>This docker instance: php -v => PHP 7.3.7 php -i |grep time provides two clues:</p>
  
  <ul>
  <li>Default timezone => UTC</li>
  <li>date.timezone => no value => no value</li>
  </ul>
  
  <p>For a D7 project on another server [works fine no +6h time issues - D7 site] -> 
  same server config (but PHP 7.1.29):</p>
  
  <ul>
  <li>CentOS is in ET (+2h) - which is fine [machine is in Toronto]</li>
  <li>Default timezone => UTC</li>
  <li>date.timezone => no value => no value</li>
  </ul>
  
  <p>So D8/PHP 7.3.7 vs D7/7.1.29</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-10-31T03:35:45.570Z
Comments.Text: What is the OS time zone? Also the time zone in php.ini (date.timezone)?
Comments.UserDisplayName: Demerit
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-10-31T12:58:50.387Z
Comments.Text: I've added some more info above. Looks like a difference in default behavior D7 vs D8 [i.e. our server / php config is the same];
Comments.UserDisplayName: KarinG - Semper IT
Tags: <timezone>
Title: Timezone issue - authenticated vs anonymous: a 6h time warp
ThreadText: # Timezone issue - authenticated vs anonymous: a 6h time warp
  
  (Asked by: username_0 on 2019-10-31)
  
  When I'm logged in -> and make a Contribution at 4:20pm - all is well!
  
  I log out and then make a Contribution through the exact same Contribution page and notice that the Contribution clocks in at 10:24pm (so +6h - that's UTC I think as I believe the UK did their timezone change last weekend);
  
  Any clues as to what may be going on here?
  This is on Drupal 8 / CiviCRM 5.15.1
  
  My default time zone in Drupal is set to Edmonton [Canada]. The 4:20pm was correct.
  
  [![enter image description here](https://i.sstatic.net/m9vn4.png)](https://i.sstatic.net/m9vn4.png)
  
  **Additional Info:**
  
  * CentOS thinks it's ET (+2h) - which is fine [machine is in Montreal];
  
  This docker instance: php -v => PHP 7.3.7 php -i |grep time provides two clues:
  
  * Default timezone => UTC
  * date.timezone => no value => no value
  
  For a D7 project on another server [works fine no +6h time issues - D7 site] ->
  same server config (but PHP 7.1.29):
  
  * CentOS is in ET (+2h) - which is fine [machine is in Toronto]
  * Default timezone => UTC
  * date.timezone => no value => no value
  
  So D8/PHP 7.3.7 vs D7/7.1.29
  
  **Tags:** timezone
  
  > **Comments:**
  > **username_1**: What is the OS time zone? Also the time zone in php.ini (date.timezone)?  
  > **username_0**: I've added some more info above. Looks like a difference in default behavior D7 vs D8 [i.e. our server / php config is the same];  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2019-10-31. Score: 1
  
  The main clue is that these date/times are being stored in mysql datetime fields, which do not include a timezone, but implicitly have a server-wide timezone (either adopted from the server, or configured explicitly).
  
  So we know that the problem is at the php level - the code is generating the date time and converting based on the current user's timezone (which it shouldn't in this case).
  
  Since it's an issue with D8 and not for D7, it seems likely that it's a D8 integration issue, some kind of automated handling of date/times that we don't want (we do want date/times to be converted to the users timezone on display).
  
  
  ---
  
  