Комментарии (7)

1. 

   maxtorchel

   19.05.2023 09:41

   #25563816

   Как раз сейчас решаю подобный вопрос, мне важно сохранять штампы времени по часовому поясу клиента в данный момент, чтобы потом кто угодно и когда угодно мог увидеть, что клиент сделал действие в определенное время по местному времени. К сожалению, все ваши рекомендации по данному поводу для меня не подходят, нужно либо хранить на каждую такую дату в соседнем поле часовой пояс, что неудобно, либо игнорировать часовой пояс и хранить просто штамп, подразумевая что это время на то место и время где клиент совершил действие. Очень жаль, что нет в mysql единого поля datetime + timezonе, можно конечно в строке хранить, но это тоже не вариант.

   
   

   1. 

      DLeo13 Автор

      19.05.2023 09:41

      #25563898

      Предварительно напишу:

      Timestamp = time in ms (UTC) from 1970/1/1 (link). Timestamp имеет формат целых чисел, iso-string имеет формат строки. В iso-string можно передать TZ, в timestamp - нет.

      Предполагаю, что разговор о логировании действий пользователя системой. Если говорить о таблице в БД, можно предположить:

      | id | user_id | action_type | time_utc                         | time_zone       |
      -----------------------------------------------------------------------------------
      | 1  | 1       | some_action | iso_string or timestamp (one of) | timezone_offset |

      В условной функции запроса по энпоинту можно совмещать в обе стороны iso-string+TZ. В любом языке данный функционал имеет место быть.

      Если речь об запросах в БД, то возможно было бы удобно создать дополнительное поле user_time в формате timestamp. Это позволит свести расчеты запросов в единую плоскость для конкретных кейсов, но выдавать другой системе для отображения и использования придется всю строку (иначе бытовые расчеты будут невозможны). Приходилось иметь дело с api, в которой очень много неясных систем отсчета, оттуда и родилась статья по унификации.

      
      

      1. 

         maxtorchel

         19.05.2023 09:41

         #25564082

         Не только логирование, я пишу программу для курьерской службы (angular+symfony), у каждой сущности может быть куча полей с датами и временем, десятки (прибытие, убытие, ожидаемое и фактическое и так далее), и всегда надо видеть это относительно того места, где посылка находится. И кстати, если ангуляру отдавать время с таймзоной то date pipe будет менять время при изменении пользователем часового пояса на своем компьютере, что тоже неприемлемо, функции игнора часового пояса у этого пайпа нет, поэтому передавать с бэка в ангуляр таймзону тоже не вариант.

         
         

         1. 

            DLeo13 Автор

            19.05.2023 09:41

            #25564506

            Пробовал вторым аргументом передавать в пайп таймзону?

            
            

            1. 

               maxtorchel

               19.05.2023 09:41

               #25564912

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

               
               

               1. 

                  DLeo13 Автор

                  19.05.2023 09:41

                  #25566080

                  Возможно для данного кейса это и будет решением, но звучит довольно дико.

                  Вместо того чтобы терять данные, я бы создал дополнительное поле. Можно добавить отдельную таблицу для отметки времени и сделать связь 1 к 1. Излишним это будет только на первый взгляд.

                  Игнорировать TZ может быть очень опасно в будущем, если, кончено, приложение будет реально использоваться в коммерции.

                  Могу предложложить сделать так:

                  • у юзера в настройках задается тайм зона, изначально берущаяся из часов

                    • в приложении будет очевидная единая тайм зона, которую можно менять при желании

                    • можно переопределять TZ автоматически при заходе юзера в приложения (добавить пункт "автоматически" в настройки юзверя)

                  • эта тайм зона будет использоваться для вставки в angular pipe вторым аргументом

                    • скорее как бонус

                  • на сервер будет отправляться время с TZ, но в базе сохраняться время UTC

                    • соблюдаем единую шкалу измерений

                  • при необходимости, можно сохранить изначальную TZ в качестве сдвига в соседнем столбце

                    • сдвиг будет легко вычислить

                  • при обмене данными FE-BE использовать iso-string, при получении на BE можно (при необходимости, например, для расчетов) использовать перевод в timestamp UTC

                    • это позволит применять расчеты в фильтре запроса к БД; все данные в единой шкале изменений и не будет проблем в вычислениях

                  Итого:

                  1. Вычисления доступны, все данные в одной системе исчеслений

                  2. Структура простая и очевидная

                  3. Структура удобна для фронта и бэка, формат унифицирован

   
   

   1. 

      me21

      19.05.2023 09:41

      #25567828

      Зачем сохранять штампы времени по часовому поясу клиента? Храните в UTC, он однозначно преобразовывается в другую таймзону, просто делайте преобразование перед показом клиенту.