Реализация функциональности, подобной IConvertible, для не модифицируемых типов

Question

У меня проблема с IConvertibleКороче: если DateTimeOffset реализованы IConvertible У меня не было бы проблемы.

Вы не можете использовать методы расширения для реализации интерфейса, так что дорога закрыта. Структура DateTimeOffset не является частичной, поэтому она не может быть расширена таким образом.

Читая в некоторых документах MSDN, я наткнулся на TypeCode enum, который необходим для корректной работы IConvertible. И, к моему разочарованию, enum также не содержит TimeSpan, что закрывает возможность использования Tuple-подобная структура с DateTime а также TimeSpan (т.е. DateTimeOffset = Р)

Мой вопрос заключается в следующем: как бы вы реализовали эквивалент DateTimeOffset, который имеет элементарную поддержку IConvertible или аналогичную поддержку?

Реализация касается реализации необычного ленивого словаря с [index,TType] where TType : IConvertible (и сеттеры, и геттеры, и триггеры), и должны иметь возможность хранить данные, специфичные для часового пояса.

Мои идеи пока:

• Создать новый ISuperConvertible интерфейс, который на самом деле является лишь продолжением IConvertible и сделать DateTimeOffset особый случай. Это сломало бы нашу поддержку IConvertible в целом, но сработало бы для этого очень конкретного случая. Плюсы и минусы?

• Используйте два "слота" для хранения DateTimeOffsets, один для DateTime и один для int смещение на полчаса (все часовые пояса не являются целыми часами =/). Тогда мы теряем cache[ApplicationStrings.LastUpdate, default : DateTimeOffset.Min] функциональность.

Те представляют мои основные мысли, то есть перерыв DateTimeOffset и хранить IConvertible или сломать IConvertible и хранить DateTimeOffset,

Я все еще плохо знаком с внутренними особенностями C#, поэтому любое понимание будет полезно. о чем ты думаешь?

РЕДАКТИРОВАТЬ: Дополнения:

• Сейчас есть работающее решение, которое использует DateTime (фиксированный часовой пояс), но теперь нужен и часовой пояс, оптимальным сценарием было бы просто использовать DateTimeOffset везде вместо этого. Вопрос по сути не в рефакторинге, а в моей конкретной проблеме.
• Это довольно большое приложение, оно использует инфраструктуру сущностей и другие более непонятные среды для взаимодействия с различными службами и хранилищами, поэтому сохранение этого типа, определенного в System, не нарушит оптимизацию LINQ-X и т. Д. (Я понятия не имею, насколько сложны эти должны сделать сами).
• Я против разделения данных, так как я не знаю, когда придет другой парень и заметит, что есть DateTime, используемый для отметки времени, и использую его без учета смещения (часового пояса).

Answer 1

Вы можете создать свой собственный класс-оболочку в DateTimeOffset, который будет реализовывать IConvertible. Этот класс будет иметь свойство DateTimeOffset, которое вы будете использовать для своих свойств и методов оболочки. И вы реализуете методы IConvertible для этого. Пример:

public class DTOffset:IConvertible
{
    private DateTimeOffset DateTimeOffset;

    //Implementation of IConvertible
    public long ToInt64(IFormatProvider provider)
    {
        return DateTimeOffset.Ticks;
    }

    public DateTime ToDateTime(IFormatProvider provider)
    {
        DateTimeOffset.DateTime;
    }
    //and so on

    //wrapper properites of DateTimeOffset:
    public int DayOfYear{get{return DateTimeOffset.DayOfYear;}}

    public DateTime Date{get{return DateTimeOffset.Date;}}
    //and so on
}