Регистрация  |  Вход

Как вы дружите Salesforce TimeZones с фронтендом (JS/MomentJS) ?

Привет народ.

В очередной раз всплыл такой жизненный вопрос.

Работы с датами и временем на фронтенде. Тема достаточно запутанная если не придавать ей должного внимания и не уделать времени на изучение.

Смысл в чем. Для того чтобы на фронтенде работать с датами обычно используют 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 и забитием болта на таймзоны в браузере такой херни не происходит :)