Привет народ.
В очередной раз всплыл такой жизненный вопрос.
Работы с датами и временем на фронтенде. Тема достаточно запутанная если не придавать ей должного внимания и не уделать времени на изучение.
Смысл в чем. Для того чтобы на фронтенде работать с датами обычно используют momentJS (если есть другие варианты предлагайте, обсудим). Так вот задача обычно такая - надо на apex дату закодировать в стрингу и передать к примеру в JSON на фронтенд. На фронтенде ее надо распарсить и получить momentJS instance для последующей работы.
Есть различные подходы как это дело решить и каждый имеет право на жизнь.
Смысл данной темы - привлечь как можно больше мнений и выработать более правильный вариант.
В примеру в моей практике используются 2 варианта:
1. берем DateTime в apex и приводим его к пользовательской таймзоне и формату через DateTime.format(<FORMAT>). На фронтенде в momentjs чтобы получить дату используем тот же <FORMAT> чтобы зату распарсить из стринги.
ПЛЮС - не надо думать про таймзоны (они есть, и они будут неправильными, но это нас не будет волновать).
МИНУС - надо на стороне apex писать логику для прямого и обратного преобразования даты. Тоесть десериализировать JSON сразу в Datetime не получится (насколько я знаю).
2. Использовать формат ISO 8601
ПЛЮС - Date/Datetime напрямую десериализируется в JSON, следовательно не надо париться по поводу преобразований даты на стороне apex.
МИНУС - наступает головная боль по поводу таймзон (кстати не такая она уж и боль если немного покурить moment-timezones).
Я придерживаюсь ВАРИАНТА №2 с ISO 8601
Как вы работаете с датами?
Привет народ. В очередной раз всплыл такой жизненный вопрос. Работы с датами и временем на фронтенде. Тема достаточно запутанная если не придавать ей должного внимания и не уделать времени на изучение. Смысл в чем. Для того чтобы на фронтенде работать с датами обычно используют momentJS (если есть другие варианты предлагайте, обсудим). Так вот задача обычно такая - надо на apex дату закодировать в стрингу и передать к примеру в JSON на фронтенд. На фронтенде ее надо распарсить и получить momentJS instance для последующей работы. Есть различные подходы как это дело решить и каждый имеет право на жизнь. Смысл данной темы - привлечь как можно больше мнений и выработать более правильный вариант. В примеру в моей практике используются 2 варианта: 1. берем DateTime в apex и приводим его к пользовательской таймзоне и формату через DateTime.format(<FORMAT>). На фронтенде в momentjs чтобы получить дату используем тот же <FORMAT> чтобы зату распарсить из стринги. ПЛЮС - не надо думать про таймзоны (они есть, и они будут неправильными, но это нас не будет волновать). МИНУС - надо на стороне apex писать логику для прямого и обратного преобразования даты. Тоесть десериализировать JSON сразу в Datetime не получится (насколько я знаю). 2. Использовать формат ISO 8601 ПЛЮС - Date/Datetime напрямую десериализируется в JSON, следовательно не надо париться по поводу преобразований даты на стороне apex. МИНУС - наступает головная боль по поводу таймзон (кстати не такая она уж и боль если немного покурить moment-timezones). Я придерживаюсь ВАРИАНТА №2 с ISO 8601 Как вы работаете с датами?
Еще в продолжение темы.
Пару раз замечал интересный подход к решению вопроса хранения "времени" в объектах SF.
Вот к примеру есть объект который должен хранить какое-то событие которое характеризуется следующими параметрами: Дата, время начала и время окончания.
Задача достаточно частая и вариантов решений я уже успел повидать достаточно.
Вижу что многие программисты так прямо и делают - одно поле для Date и 2 поля для Start и End Times с типом String.
Почему время хранится в String? А вот это как раз вопрос. Мне например этот вариант не нравится. Для меня если есть время значит должен быть DateTime по-любому. То есть время хранить отдельно от даты нонсенс. Я понимаю что в качестве простого стринга время меньше ипет мозг, но я не думаю что это исключает все проблемы.
!ВОТ К ПРИМЕРУ ПОДОСПЕЛ АПДЕЙТ В SF - добавили поле Time. Интересно как оно будет работать и будет ли учитывать таймзоны и DST.
Еще в продолжение темы. Пару раз замечал интересный подход к решению вопроса хранения "времени" в объектах SF. Вот к примеру есть объект который должен хранить какое-то событие которое характеризуется следующими параметрами: Дата, время начала и время окончания. Задача достаточно частая и вариантов решений я уже успел повидать достаточно. Вижу что многие программисты так прямо и делают - одно поле для Date и 2 поля для Start и End Times с типом String. Почему время хранится в String? А вот это как раз вопрос. Мне например этот вариант не нравится. Для меня если есть время значит должен быть DateTime по-любому. То есть время хранить отдельно от даты нонсенс. Я понимаю что в качестве простого стринга время меньше ипет мозг, но я не думаю что это исключает все проблемы. !ВОТ К ПРИМЕРУ ПОДОСПЕЛ АПДЕЙТ В SF - добавили поле Time. Интересно как оно будет работать и будет ли учитывать таймзоны и DST.
Вот еще одна интересная ситуация с timezonses во фронтенде + SF.
Скажем мы находимся в другой таймзоне (в SF стоит скажем +3 а в браузере +5).
Проблем нет если мы имеем дату в UTC+0 и отображаем ее в таймзоне из SF.
moment.tz.setDefault(...)
И момент работает как будто он переехал в таймхону из SF.
Но вот надо поставить текущее время.
moment().format('L LT Z')
и что мы видим - текущее время в таймзоне SF но не текущее время на компе.
С одной стороны это логично, с другой нет.
Вот еще одна интересная ситуация с timezonses во фронтенде + SF. Скажем мы находимся в другой таймзоне (в SF стоит скажем +3 а в браузере +5). Проблем нет если мы имеем дату в UTC+0 и отображаем ее в таймзоне из SF. moment.tz.setDefault(...) И момент работает как будто он переехал в таймхону из SF. Но вот надо поставить текущее время. moment().format('L LT Z') и что мы видим - текущее время в таймзоне SF но не текущее время на компе. С одной стороны это логично, с другой нет.
О!!!!!!!!!!!
Вот как раз и пришла отличная идея.
Раз ситуация двоякая когда браузер смотался в другую таймзону - нехрен городить огород.
Надо переключать momentJS в таймзону SF а в случае если зоны не совпадают показывать предупреждение мол вы находитесь в другой таймзоне и разница во времени такая-то.
Да, с парсингом на стороне SF и забитием болта на таймзоны в браузере такой херни не происходит
О!!!!!!!!!!! Вот как раз и пришла отличная идея. Раз ситуация двоякая когда браузер смотался в другую таймзону - нехрен городить огород. Надо переключать momentJS в таймзону SF а в случае если зоны не совпадают показывать предупреждение мол вы находитесь в другой таймзоне и разница во времени такая-то. Да, с парсингом на стороне SF и забитием болта на таймзоны в браузере такой херни не происходит :)