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

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

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

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

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

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

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

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

http://everytimezone.com/#2013-8-27,-420,6bj


time datetime date-arithmetic timezone-offset timezone
person Kirk Ouimet    schedule 28.08.2013    source источник

Ответы (1)


arrow_upward
1
arrow_downward

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

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

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

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

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

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

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

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

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

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

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

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

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

person Matt Johnson-Pint    schedule 28.08.2013