DateTimeOffset(Strict)
Сегодня утром мой приятель kirillkos столкнулся с проблемой.
Проблемный код
Вот его код:
class Event {
public string Message {get;set;}
public DateTime EventTime {get;set;}
}
interface IEventProvider {
IEnumerable GetEvents();
}
И дальше много-много реализаций IEventProvider, достающие данные из разных таблиц и баз.
Проблема: во всех этих базах все в разных временных зонах. Соответственно, при попытке вывести события на UI все ужасно перепутано.
Слава Хейлсбергу, у нас есть типы, пусть они спасут нас!
Попытка 1
class Event {
public string Message {get;set;}
public DateTimeOffset EventTime {get;set; }
}
DateTimeOffset замечательный тип, он хранит информацию о смещении относительно UTC. Он прекрасно поддерживается MS SQL и Entity Framework (а в версии 6.3 будет поддерживаться еще лучше). У нас в code style он обязательный для всего нового кода.
Теперь мы можем собрать информацию с этих самых provider и консистентно, полагаясь на типы, вывести все на UI. Победа!
Проблема: DateTimeOffset умеет неявно преобразовываться из DateTime.
Следующий код прекрасно скомпилируется:
class Event {
public string Message {get;set;}
public DateTimeOffset EventTime {get;set; }
}
IEnumerable GetEvents()
{
return new[] {
new Event() {EventTime = DateTime.Now, Message = "Hello from unknown time!"},
};
}
Это потому, что у DateTimeOffset определен оператор неявного приведения типов:
// Local and Unspecified are both treated as Local
public static implicit operator DateTimeOffset (DateTime dateTime);
Это совсем не то, что нам нужно. Мы-то хотели, чтобы программист при написании кода был вынужден задуматься: «а в какой собственной временной зоне случилось это событие? Откуда взять зону?». Часто совсем из других полей, иногда из связанных таблиц. А тут совершить ошибку не задумавшись очень легко.
Проклятые неявные преобразования!
Попытка 2
С тех пор, как я услышал про молоток статические анализаторы, мне все кажется гвоздями подходящими случаями для них. Нам надо написать статический анализатор, который запрещает это неявное преобразование, и объясняет почему… Выглядит, как многовато работы. Да и вообще, это работа компилятора, проверять типы. Пока отложим эту идею, как многословную.
Попытка 3
Вот если мы были бы в мире F#, сказал kirillkos.
Мы бы тогда:
type DateTimeOffsetStrict = Value of DateTimeOffset
И дальше не придумал импровизируй какая-то магия нас спасла бы. Жаль, что у нас в конторе не пишут на F#, да и мы с kirillkos его толком не знаем :-)
Попытка 4
Неужели что-то такое нельзя сделать на C#? Можно, но замучаешься преобразовывать туда-сюда. Стоп, но ведь мы только что видели, как можно сделать неявные преобразования!
///
/// Same as
public readonly struct DateTimeOffsetStrict
{
private DateTimeOffset Internal { get; }
private DateTimeOffsetStrict(DateTimeOffset @internal)
{
Internal = @internal;
}
public static implicit operator DateTimeOffsetStrict(DateTimeOffset dto)
=> new DateTimeOffsetStrict(dto);
public static implicit operator DateTimeOffset(DateTimeOffsetStrict strict)
=> strict.Internal;
}
Самое интересное в этом типе, что он неявно преобразуется туда-сюда из DateTimeOffset, а вот попытка неявно преобразовать его из DateTime вызовет ошибку компиляции, преобразования из DateTime возможны только явные. Компилятор не может вызвать «цепочку» неявных преобразований, если они определены в нашем коде, это ему запрещает стандарт (цитата на SO). То есть, вот так работает:
class Event {
public string Message {get;set;}
public DateTimeOffsetStrict EventTime {get;set; }
}
IEnumerable GetEvents()
{
return new[] {
new Event() {EventTime = DateTimeOffset.Now, Message = "Hello from unknown time!"},
};
}
а вот так нет:
IEnumerable GetEvents()
{
return new[] {
new Event() {EventTime = DateTime.Now, Message = "Hello from unknown time!"},
};
}
Что нам и требовалось!
Итог
Пока не знаем, будем ли внедрять. Только всех приучили к DateTimeOffset, и теперь его заменять на наш тип — стремновато. Да и наверняка всплывут проблемы на уровне EF, ASP.NET parameter binding и еще в тысяче мест. Но самое решение кажется мне интересным. Аналогичные трюки я использовал, чтобы следить за безопасностью пользовательского ввода — делал тип UnsafeHtml, который неявно преобразуется из строки, а вот обратно его преобразовать в строку или IHtmlString можно только путем вызова sanitizer.
