У меня есть база данных, содержащая временные метки UTC (GMT+0). Вот в чем проблема: они ссылаются на выставление счетов в штате Индиана.
Как некоторые могут знать, Индиана...
- до 2006 года вообще не соблюдали летнее время (большая часть штата была EST в течение всего года).
- в 2006 году проголосовали за то, чтобы остаться EST, но начать соблюдать летнее время с остальной частью США.
- пересмотрел свои правила в 2007 году; Федеральное правительство США пересмотрело летнее время, чтобы изменить правила начала и окончания
Поскольку временные метки в этой базе данных относятся к действиям правительства по выставлению счетов, на самом деле необходимо, чтобы временные метки UTC сообщались как местное время, которое является исторически точным, чтобы сохранить точность аудита. Таким образом, есть три сценария, которые применимы исключительно к Индиане: метки времени до 2006 года используют совершенно другой набор правил часового пояса, чем между 2006-2007 годами, а после 2007 года используется совершенно другой набор правил часового пояса. Вы можете себе представить, что эта база данных включает в себя действия для локалей, отличных от Индианы, и поэтому все становится еще сложнее.
Календарь Java и API TimeZone не содержат классов, которые позволяют программисту создавать объекты с более чем одним набором правил часового пояса, и поэтому их нельзя использовать для правильного сопоставления временных меток UTC с исторически точным местным временем, если конкретный применимый часовой пояс правила когда-нибудь меняются.
Я думал о способах решения проблемы сопоставления с исторически точным местным временем в регионах с изменением правил часового пояса...
База данных может быть обновлена, чтобы метки времени UTC могли храниться вместе со смещением местного времени и смещением летнего времени. Проблема здесь в том, что размер базы данных немного увеличивается, и если существующая база данных велика, то для обновления всех таблиц может потребоваться длительный автономный цикл обслуживания.
База данных может быть обновлена таким образом, чтобы конкретный объект TimeZone, соответствующий этой конкретной временной метке, сохранялся с каждой временной меткой. Хотя я думаю, что объекты TimeZone довольно легкие, я вижу, что это более гибко, чем выше, но все же менее желательно, поскольку требует сохранения объекта для каждой временной метки.
Можно разработать собственный API, который создает соответствующий объект TimeZone из базы данных исторически точных правил для интересующих локалей. Это решение заменяет повышенные требования к хранилищу двух предыдущих решений необходимостью дополнительной обработки. Каждая отметка времени, которую необходимо отображать, будет означать создание нового объекта... или, по крайней мере, сопряжение с соответствующим объектом из пула объектов. Кроме того, это означает создание и администрирование базы данных часовых поясов.
Ограничения API времени и календаря Java сделали поиск элегантного решения этой проблемы действительно более сложным, чем должно быть (вы не можете, например, запросить существующий объект SimpleTimeZone и спросить его, каким правилам перехода на летнее время он следует без написания некоторых действительно грязный код).
Я просто хотел бы спросить, сталкивался ли кто-нибудь с такой ситуацией раньше и как они с этим справились.
