Я уже поправил. Извините, на Урале уже вечер, формулируется тяжко)

... Ты знаешь, это звучало... Мммммммм.   %)

лагавулин в целом тоже норм вариант

Так уже интереснее :D

"Lagavulin" malt 16 years old, with box, 0.75 л вот такой, наапример

поправил пин

алкашка в качестве благодарности тоже в списке опций

Вообще, конечно, клиент сам должен таймстэмп в ISO 8601 из ответа в свою таймзону пересчитывать.

Нормальных выходов два:
1. Открытый конфликт с отстаиванием полномочий в своей зоне ответственности.
2. Расширить возможности системы так, чтобы стал учитываться рассматриваемый кейс. Например, при логине можно принимать таймзону параметром, хранить её в сессии, и пересчитывать в неё отдаваемые таймстэмпы. Систему такое решение сильно не испортит - чуток декораторов добавится и всё, но все равно это довольно бессмысленная функциональность.

Ломать все «реализацией по ТЗ» не вариант - клиентов жалко, а «эффективные» менеджеры из своих ошибок выводов все равно обычно не делают.

Эх

тут на одной конфе был прекрасный кейс

как сервер получает дату-время с таймзоной
скажем, 9 утра местного времени
сохраняет в базу в unixtime плюс инфу о таймзоне
на завтра достает из базы и получает 10 утра местного времени

а курьер уже уехал и долбится уже час в дверь клиента

так что всё это фигня и не работает...

таймзона, конечно же, была та же

ладно таймзоны, в некоторых местах (Таиланд) вообще 2564 год уже )

да, но
вряд ли в Таиланде после 2564 года наступит 2566
хотя, конечно, исключать этого нельзя

А есть тест кейс чтобы повторить?

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

Звучит как зимнелетнее время, но кто-то забыл

конечно
но вам надо переместиться в 2014 год в Самару

звучит как изменение смещения внутри таймзоны по политическим причинам