How to setup timezones for members?

[Sonya*]

After upgrading to 4.3.6 we have issues with timezones. Some users have 1 hour offset, another 6 hours from their real time. In our custom module we do not allow to enter data with date in the future. Now the user has actually 20.11 but our website "thinks" there still were 19.11 and shows an error. The date is 6 hours after the member's real date. Other users have the same problem, the time difference for them varies from 1 to 7 hours.

I am not sure how can I handle the issue? How timezone of user is detected in 4.3.6 and how the member can change it when automatic detection is false?

[bfarber]

We use javascript to detect the user's time zone, which is pretty accurate overall.

If you think this isn't working correctly on your site for some reason I'd recommend submitting a ticket.

If the issue is with a custom module and a user manually entering a date, I think you should spend some time leveraging the \IPS\DateTime class to translate times/dates appropriately based on the user's time zone. Perhaps if you can show a code example that highlights the problem you're experiencing, we can provide some further guidance.

[Sonya*]

Think about calendar/diary where users save their entries. There is only one entry per day allowed. By default the form is filled with "today" date. I create the date this way:

$tdate = \IPS\DateTime::create();
$tdate = $tdate->format('Y-m-d');
list($y, $m, $d) = explode('-', $tdate);

I use Date field to allow to choose another date, but there is a restriction for no dates in the future like this:

new \IPS\Helpers\Form\Date('jump_to', \IPS\DateTime::create()->setDate($y, $m, $d), TRUE, array('max' => new \IPS\DateTime()));

My issue is that when some users would like to enter his data and open the form, the date field is prefilled with "yesterday" date. They have to wait up to 7 hours until they are able to save their data with correct date. What is wrong with this code?

 

[bfarber]

In place of \IPS\DateTime::create() and new \IPS\DateTime try

\IPS\DateTime::ts( time() )

See if that resolves the issue. The ts() method (unless you adjust the second parameter) handles the logged in member's time zone, while using the create() shortcut or the main constructor does not (you have to manually set the timezone), which I think is where you're running into trouble.

[Sonya*]

This indeed has solved the issue entirely. I have looked up in the database to check if the timezone is saved correctly for the users in question. And yes, there was correct setting in core_members table field timezone. Means it would not have solved the issue to manually set their timezone.