#Azure Storage Tables – DateTime.MinValue is not Within the Supported DateTime Range

Azure Table Storage is a NoSQL storage key/value based part of Microsoft Azure Storage services. It’s really good at absorbing massive amounts of data. It’s really good at massive parallel operations work on small amounts of data. But it’s horrible when it comes time to extract large amounts of data in a serial manner. We’ll get to that topic in a future post.

DateTime is a type that is used to represent time in .NET. We use it very liberally without much afterthought. But when we start playing with Azure Table Storage, we have to think about the supported DateTime range. At this time, it’s also important to note that the local Azure Storage Emulators run on various database flavors like SQL Server and LocalDB. These databases do not impose the same limitations for DateTime values. Therefore, this bug will only show up on Microsoft Azure.

In order to limit headaches, I’m providing the following table to help identify what is supported and what isn’t.

Common Language Runtime type	Details
byte[]	An array of bytes up to 64 KB in size.
bool	A Boolean value.
DateTime	A 64-bit value expressed as Coordinated Universal Time (UTC). The supported DateTime range begins from 12:00 midnight, January 1, 1601 A.D. (C.E.), UTC. The range ends at December 31, 9999.
double	A 64-bit floating point value.
Guid	A 128-bit globally unique identifier.
Int32 or int	A 32-bit integer.
Int64 or long	A 64-bit integer.
String	A UTF-16-encoded value. String values may be up to 64 KB in size.

Find out More about Azure Storage

• Understanding the Table Service Data Model
• Migrating Data to Azure Table Storage
• Azure Table Storage and Azure SQL Database – Compared and Contrasted

Consider Using UTC (Coordinated Universal Time) When Designing REST APIs

With an ecosystem of devices that is constantly evolving, it’s hard to predict who will consume your REST APIs and how they will consume them. Devices as we know them are changing shape, consequently applications are constantly adapting to new platforms.

Lets face it, mobile apps are the norm and shouldn’t be ignored. They travel and shouldn’t be considered as sedentary.

Imagine a scenario where you are on a business trip and try to fetch today’s news from a different continent. Your device formulates a URI with a date and calls a service… no results…
That’s weird! Its 10 PM and I should get results for today’s news. This is probably the moment where you realize that you aren’t in your normal time zone… your phone has adapted to your new geographic location but the APIs the app is calling has not!

Running Code on Windows Azure? Set the time zone of your development machine to UTC (Coordinated Universal Time)!

Its no secret that Windows Azure Roles, Services and SQL Database Time Zones  are set to
UTC (Coordinated Universal Time). Forgetting this fact can get us in trouble! When we forget about
Time Zones, any operations dealing with dates and times are potential bugs!

For example

• Scheduling jobs
• Comparing dates and times
• Performing operations on dates and times
• Parsing string dates and times from the client
• Storing dates and times in SQL Database

We naturally refer to time using our current Time Zone. Imagine that a system requires a specific Job to run every Monday at 16h05 GMT –5. Its very likely that I will create a new DateTime instance that represents 16h05 and that I will happily use it to schedule my daily Job.