cotonti.com : Timezone GMT https://www.cotonti.com Last topic posts Cotonti en Tue, 07 Apr 2026 16:36:56 -0000 Kopusha Ну тогда время будет у юзеро одинаковое) 
Как я и думал "ну не могли же не предусмотреть такой поворот" и действительно.

function cot_date($format, $timestamp = null, $usertimezone = true)

Чуть поиграться и заработает.

Added 19 minutes later:

И с этим поиграться

function cot_selectbox_date($utime, $mode = 'long', $name = '', $max_year = 2050, $min_year = 2017, $usertimezone = true, $custom_rc = '')

 

]]> Wed, 30 Sep 2020 19:08:03 -0000 Виктор интересная ситуация, если это биржа наверное лучше поставить всем GMT одинаковый, могут возникать спорные ситуации

]]> Wed, 30 Sep 2020 17:41:21 -0000 Kopusha В данный момент наблюдаю такое
Пользователь с GMT добавил project, дата 10/02/2020 - 2 октября. В бд она в виде 1601596800

Открываю со своего профиля где GMT минус 10 и вижу 10/01/2020. Что вполне логично. Но неверно.

Added 4 minutes later:

Ну и в projects.tpl юзер сейчас видит October 02, 2020 а я. - October 01.
Что бы исключить всякие нюансы с экстраполями и тем что я обрабатываю дату яваскриптом - залил folio в другом модуле этим же юзеров - у него дата item_date = Today at 5:28 PM а у меня Today at 7:28 AM.

Added 36 seconds later:

item_date не трогал в folio ничем, самое стандартное поле от биржи.

Added 1 minute later:

Более того - этот комментарий я написал 2020-09-30 17:26 а переключив GMT уже вижу 2020-09-30 06:26

Added 2 minutes later:

Все таки GMT нужно и удобно - я выставил себе свой GMT +2 и уже этот комментарий в правильное время написан -2020-09-30 20:26 Надо наверное как то при модерации дергать разницу во времени модератора с GMT и ее не учитывать...Что бы не подменяло даты.

]]> Wed, 30 Sep 2020 17:26:11 -0000 Виктор #45092 Kopusha:

Подскажите куда копать.
Пользователь заливает элемент на модерацию и в нем есть кастомное поле date с датой. Указал 2 октября. У пользователя стоит GMT в профиле.
Элемент попадает на модерацию к другому пользователю у которого в профиле GMT плюс либо минус 10-12 часов и уже в открываемом элементе это поле равно 1 октября или третье. Естественно при модерации дата слетает. 
Как примерно можно с таким попробовать бороться?

если элемент  уже на модерации значит дата прописана в таблице в виде 1601484270, почему она должна слетать?

cot_selectbox_date($db['1601484270'].....

]]> Wed, 30 Sep 2020 17:20:44 -0000 Kopusha Что такое "хранить в своем стандартном GMT"?

 

Added 2 minutes later:

Хранить сразу в виде даты вряд ли получится по целому ряду причин, нужно хранить именно в виде 1601484270. Я много где это поле сравниваю с sys now, вывожу для EN версии в виде 10/02/2020 а UA 02.10.2020...

Added 1 minute later:

Проще всего конечно просто принудительно поставить всем GMT и убрать из профиля возможность изменения.
Для чего в принципе надо менять себе пояс? Может есть какие то кейсы где это необходимо?

]]> Wed, 30 Sep 2020 17:05:55 -0000 jCube Group Поле можно хранить сразу ввиде даты,  или хранить и показывать в своем стандартном GMT  и если нужно то указать мелким шрифтом что это в GMT 0 к примеру.

]]> Wed, 30 Sep 2020 16:50:58 -0000 Kopusha Подскажите куда копать.
Пользователь заливает элемент на модерацию и в нем есть кастомное поле date с датой. Указал 2 октября. У пользователя стоит GMT в профиле.
Элемент попадает на модерацию к другому пользователю у которого в профиле GMT плюс либо минус 10-12 часов и уже в открываемом элементе это поле равно 1 октября или третье. Естественно при модерации дата слетает. 
Как примерно можно с таким попробовать бороться?

]]> Wed, 30 Sep 2020 16:24:37 -0000