4

Before anyone closes this as a duplicate, I am aware that Azure Table Storage doesn't support the DateTimeOffset type natively (MSDN states as much; trying to read and write entities having DateTimeOffset properties doesn't throw an exception, but doesn't maintain the correct timestamps either).

My question is why isn't this data type supported, particularly as it already existed when Azure was created. What's even more confusing is that the .NET API for Azure Table Storage seems to offer support for the data type: entities get converted into a dictionary of EntityProperty values, and the EntityProperty class has both a DateTimeOffsetValue property and a constructor that takes a value of that type. Seems odd that they would add this support in the API if the Azure side of things doesn't support the type anyway.

Steven Rands
  • 5,160
  • 3
  • 27
  • 56
  • 4
    I'm voting to close this question as off-topic because it looks like it was by choice for whatever reasons the MS team had (time constraints?). Asking it here is calling for speculation. – Eddy Feb 23 '15 at 14:28
  • 2
    I disagree that it's calling for speculation. Microsoft links to Stack Overflow as one of two suggested forums for asking questions about Azure (the other forum they suggest is MSDN). Asking this question here is calling for someone who knows the answer to respond. If someone doesn't know the answer to this question but wants to present speculation as fact then that's their problem, not the question's. – Adam Goodwin Jan 30 '16 at 07:38

1 Answers1

3

Actually it is supported, what happened is server side converts a local DateTimeOffset to standard UTC.

For example the sent entity has – 

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

Then the returned entity has –

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

The server will return the UTC DateTimeOffset since there is no way to figure out if end-user created a DateTimeOffset using local or UTC times while sending.

Jason Tang - MSFT
  • 330
  • 2
  • 9
  • 5
    Thanks for the response. I would agree that `DateTimeOffset` is supported by the Azure Table Storage _.NET API_ but it seems pretty obvious that on the cloud side of things the `DateTimeOffset` type is not supported natively, only the regular `DateTime` type, which is why the .NET API has to perform the conversion from one type to the other. My question was really asking why `DateTimeOffset` is not supported as a type on the cloud side. – Steven Rands Mar 03 '15 at 10:41
  • 1
    Technically you can pass DateTimeOffset BUT its handling is wrong!, IMO it is a bug on the server side and we can't say that the type is supported. Because of this I was forced to store DateTimeOffset as string in ISO 8601 format – Andrzej Martyna Jan 25 '19 at 12:17