Проблемы с часовым поясом при расчете дневной и годовой прибыли

Question

Хорошо, вот жесткий вопрос, для которого я и мой друг обсуждаем правильное решение для программирования.

Допустим, я веду бизнес в Нью-Йорке во время UTC-4.

Мой торговый представитель в Сан-Франциско, чье время 31 декабря 2013 года - 23:00 (в мое время это 1:00 утра 1 января 2014 года), совершает продажу, которая приносит компании 1 000 000 долларов США. Он поступает в продажу в системе, как это происходит 31 декабря 2013 года, но на самом деле, в мое время, это происходит 1 января 2014 года.

Включаю ли я в отчет за 2013 год 1 000 000 долларов США в качестве прибыли или это отражено в моем отчете за 2014 год?

Смежный вопрос, который нужно решить, - как большинство компаний рассчитывают ежедневные продажи за 31 декабря? Это последние 24 часа с полуночи в часовом поясе штаб-квартиры компании или 31 декабря для каждого из часовых поясов этого рынка?

Кроме того, если у вас есть только дата (ГГГГ-ММ-ДД), введенная для продажи, как конвертировать ее, хранящуюся в UTC, если день UTC распространяется на две уникальные даты?

Вот полезный инструмент, который я использовал для анализа этого вопроса:

http://everytimezone.com/

Answer 1

С практической точки зрения:

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

• Некоторые предприятия могут использовать часовой пояс своей штаб-квартиры, а некоторые могут использовать время места, где была сделана продажа. Любой подход может быть действительным.

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

Что касается технических деталей на ваш вопрос:

• Дата без времени или часового пояса - это просто дата. Думайте об этом как о логической позиции в календаре, а не как об уникальном моменте мгновенного времени.

• Без дополнительного контекста вы не можете конвертировать его в UTC. Или любой другой часовой пояс в этом отношении.

• Поскольку UTC является системой учета времени, а не часовым поясом, технически не существует такого понятия, как день UTC, но это просто семантика. Тем не менее, идея "дня UTC" будет охватывать только одну календарную "дату", поскольку это является частью определения того, что такое "дата".

• Просто "день UTC" не совпадает с "днем Нью-Йорка". Точно так же, как "день в Нью-Йорке" не совсем совпадает с "днем в Лос-Анджелесе".

• Чтобы поразить вас еще сильнее, учтите, что не каждый местный день длится 24 часа. Из-за переходов на летнее время "день" может длиться 23, 23,5, 24, 24,5 или 25 часов. Конечно, большинство из них являются "стандартными днями", которые составляют ровно 24 часа.

• Если вы можете отделить, что местное время - это позиция в календаре, а мгновенное время универсально, то вы обнаружите, что все это имеет смысл.

• Сайт, на который вы ссылались, имеет приятную визуализацию, и я часто на него ссылаюсь. Но ИМХО у него должно быть другое имя, потому что оно не охватывает каждый часовой пояс. Используйте это осторожно. См. Базу данных IANA, в которой обсуждается тег wiki для часовых поясов, в котором более 500 зон.

• Я не знаю, какой язык или базу данных вы используете, но вам могут пригодиться концепции, которые я недавно описывал в этом посте по работе с датой и временем в RavenDB. В частности, прочитайте раздел "Преобразование часовых поясов". Даже если вы используете какую-то другую технологию, будут применяться те же понятия.