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

Question

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

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

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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

• Просто «день UTC» не соответствует «нью-йоркскому дню». Точно так же, как «Нью-йоркский день» не идеально сочетается с «днем Лос-Анджелеса».

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

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

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

• Я не знаю, какой язык или базу данных вы используете, но вы можете найти концепции, которые я недавно описал в this post on working with Date and Time in RavenDB. В частности, прочитайте раздел «Конверсии часовых поясов». Даже если вы используете некоторые другие технологии, будут применяться те же концепции.