Azure proxy handles Date fields incorrectly by default

If you have a date field in your model, and that model is stored in Azure via an AzureStore and AzureProxy, then if you create your first model like this:

Code:

Ext.define('App.model.Thing', {
  extend: 'Ext.data.Model',
  requires: ['Ext.data.Field'],
  config: {
    fields: [
      {name: 'date', type: 'date'}
    ]
  }
});

Ext.define('App.store.AzureStore', {
    extend: 'Ext.azure.Store',

    requires: [
        'App.model.Thing',
        'Ext.azure.Proxy'
    ],

    config: {
        model: 'App.model.Thing',
        storeId: 'Things',
        proxy: {
            type: 'azure',
            tableName: 'Thing'
        }
    }
});


var record = Ext.create('App.model.Thing', {
  date: new Date()
});

var azureStore = Ext.getStore('Things');
azureStore.add(record);
azureStore.sync();

on Azure, it will create 'date' column with type 'number', not 'date', and it will store the date as a timestamp, e.g., 1388556000 for January 1, 2014.

Then, we you try to load data from the store, the framework throws an exception in Types.js:

Uncaught TypeError: undefined is not a function Types.js?_dc=1400521447028:195

Ext.apply.DATE.convert Types.js?_dc=1400521447028:195

Ext.define.setData Model.js?_dc=1400521447015:660

Ext.define.constructor Model.js?_dc=1400521447015:550

Class sencha-touch.js:5267

Ext.define.processRead Operation.js?_dc=1400521447164:348

Ext.define.process Operation.js?_dc=1400521447164:336

Ext.define.processResponse Server.js?_dc=1400521447110:244

Base.implement.callParent sencha-touch.js:4715

Ext.define.processResponse Proxy.js?_dc=1400521447022:336

(anonymous function) Ajax.js?_dc=1400521447045:338

Ext.apply.callback sencha-touch.js:10397

Ext.define.onComplete Connection.js?_dc=1400521447167:912

Ext.define.onStateChange Connection.js?_dc=1400521447167:846

You can fix the loading problem by setting the datefield's dateFormat to 'timestamp', but you're still stuck with a number field on Azure, not a date field.

It would be great if the Azure plugin could serialize and deserialize date fields in a fully Azure-compatible way by default.

I'm sorry I can't provide a standalone test case, but I don't think that's possible without revealing my private Azure app-key and app-url.