[Tables] Inconsistent timestamp type

[joheredi]

Which service(blob, file, queue, table) does this issue concern?

Tables

Which version of the Azurite was used?

3.14.3

Where do you get Azurite? (npm, DockerHub, NuGet, Visual Studio Code Extension)

npm

What's the Node.js version?

v14.17.5

What problem was encountered?

COSMOS and Storage return timestamp as a string while Azurite as a DateTime instead

Azurite:

'{"odata.metadata":"http://127.0.0.1:10002/devstoreaccount1/$metadata#emuvsreal/@Element", "odata.etag":"W/\"datetime'2021-11-09T03%3A14%3A44.4640000Z'\"","PartitionKey":"1","RowKey":"1","foo":"foo","[email protected]":"Edm.DateTime","Timestamp":"2021-11-09T03:14:44.4640000Z"}'

Cosmose & Storage

{"odata.metadata":"https://.table.core.windows.net/$metadata#emuvsreal/@Element","odata.etag":"W/\"datetime'2021-11-09T03%3A14%3A44.2083466Z'\"","PartitionKey":"1","RowKey":"1","Timestamp":"2021-11-09T03:14:44.2083466Z","foo":"foo"}'

Steps to reproduce the issue?

Just call "GET /devstoreaccount1/emuvsreal(PartitionKey='1',RowKey='1') HTTP/1.1" on any entity and compare with the response of getting entities vs the real service (either COSMOS or STORAGE)

Have you found a mitigation/solution?

[edwin-huber]

Thanks for reporting this. We are looking into it.

[edwin-huber]

I can confirm the issue when testing with minimal metadata, Header: Accept Value: application/json;odata=minimalmetadata

Our documentation does show that we do not return the odata type for the TimeStamp in that scenario: https://docs.microsoft.com/en-us/rest/api/storageservices/query-entities

Please be advised however, that this is an odata type, and is Edm.DateTimeeven if this is not returned in the minimal metadata response for Timestamp.

Using an accept header with full metadata will return the odata type for the timestamp as well. Both the original Storage SDK and Data-Tables SDKs handle this response without issues.

I'll remove the odata Type from the responses to maintain parity with the service. Thanks for letting us know!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[edwin-huber]

pending PR