2015-02-23 3 views
3

Прежде чем кто-нибудь закроет это как дубликат, я знаю, что Azure Table Storage не поддерживает тип DateTimeOffset изначально (MSDN states as much; попытка чтения и записи объектов, имеющих DateTimeOffset, свойства не генерируют исключения, но не поддерживают правильные временные метки).Почему Azure Table Storage не поддерживает DateTimeOffset?

Мой вопрос: почему не является Этот тип данных поддерживается, в частности, поскольку он уже существовал при создании Azure. Еще более запутанным является то, что .NET API для хранилища таблиц Azure предлагает поддержку типа данных: сущности преобразуются в словарь значений EntityProperty, а класс EntityProperty имеет как свойство DateTimeOffsetValue, так и конструктор, который принимает значение этот тип. Кажется странным, что они добавят эту поддержку в API, если сторона Azure не поддерживает тип в любом случае.

+4

Я голосую, чтобы закрыть этот вопрос как не по теме, потому что, по-видимому, он по выбору по каким-то причинам имел команду MS (временные ограничения?). Просить об этом здесь требует спекуляции. – Eddy

+1

Я не согласен, что он призывает к спекуляции. Microsoft ссылается на Stack Overflow как на один из двух предложенных форумов для вопросов о Azure (другой форум, который они предлагают, это MSDN). Задавать этот вопрос здесь - это призыв к тому, кто знает ответ на ответ. Если кто-то не знает ответа на этот вопрос, но хочет представить спекуляцию как факт, то это их проблема, а не вопрос. –

ответ

1

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

Например отправленное предприятие имеет -

sendEnt.DateTimeOffset 
{2/25/2015 6:55:46 PM -08:00} 
    Date: {2/25/2015 12:00:00 AM} 
    DateTime: {2/25/2015 6:55:46 PM} 
    Day: 25 
    DayOfWeek: Wednesday 
    DayOfYear: 56 
    Hour: 18 
    LocalDateTime: {2/25/2015 6:55:46 PM} 
    Millisecond: 229 
    Minute: 55 
    Month: 2 
    Offset: {-08:00:00} 
    Second: 46 
    Ticks: 635604873462293981 
    TimeOfDay: {18:55:46.2293981} 
    UtcDateTime: {2/26/2015 2:55:46 AM} 
    UtcTicks: 635605161462293981 

Тогда возвращаемый объект имеет -

retrievedEntity.DateTimeOffset 
{2/26/2015 2:55:46 AM +00:00} 
    Date: {2/26/2015 12:00:00 AM} 
    DateTime: {2/26/2015 2:55:46 AM} 
    Day: 26 
    DayOfWeek: Thursday 
    DayOfYear: 57 
    Hour: 2 
    LocalDateTime: {2/25/2015 6:55:46 PM} 
    Millisecond: 229 
    Minute: 55 
    Month: 2 
    Offset: {00:00:00} 
    Second: 46 
    Ticks: 635605161462293981 
    TimeOfDay: {02:55:46.2293981} 
    UtcDateTime: {2/26/2015 2:55:46 AM} 
    UtcTicks: 635605161462293981 
    Year: 2015 

Сервер возвращает UTC DateTimeOffset, так как нет никакого способа, чтобы выяснить, если конечный пользователь созданный DateTimeOffset, используя локальные или UTC раз при отправке.

+2

Спасибо за ответ. Я бы согласился с тем, что 'DateTimeOffset' поддерживается API-интерфейсом Azure Table Storage _.NET API, но кажется довольно очевидным, что на стороне облаков тип' DateTimeOffset' не поддерживается изначально, используется только обычный тип 'DateTime', который почему .NET API должен выполнять преобразование из одного типа в другое. Мой вопрос действительно спрашивал, почему 'DateTimeOffset' не поддерживается как тип на стороне облака. –

Смежные вопросы