+1 agree on all fronts. Dan
-----Original Message----- From: Jmeas Apache [mailto:[email protected]] Sent: Thursday, August 07, 2014 12:09 PM To: [email protected] Subject: Re: Angular branch: Returning dates as ISO 8601 strings *The follow-up question is should the server always store/send time in UTC?Personally I think that is cleaner if the server always operates in UTC andthe UI has the ability to convert to whatever time the user wants.* Agreed. On Thu, Aug 7, 2014 at 11:58 AM, Chris Geer <[email protected]> wrote: > +1 I agree, the API should always use ISO 8601 date/times. > > The follow-up question is should the server always store/send time in UTC? > Personally I think that is cleaner if the server always operates in UTC and > the UI has the ability to convert to whatever time the user wants. > > Chris > > > On Thu, Aug 7, 2014 at 7:22 AM, Jmeas Apache <[email protected]> > wrote: > > > Some data is stored – or at least presented – in the 'YYYY-MM-DD > > hh:mm:ss' format > > within Rave. An example of this can be seen in the creation datetime and > > modified datetime for the Categories section of the admin. > > > > I propose that the API return the dates as an ISO 8601 string: ' > > YYYY-MM-DDTHH:mm:ssZ'. The benefits of this is that it's more easily > parsed > > by libraries like Angular (ng-date) and moment.js. And, of course, once > one > > of these libraries parses a date you have the full functionality of the > > library available to you. ng-date is a great filter that lets us present > > the datetimes in a more human-readable format, and moment.js is the de > > facto solution to doing anything beyond the simplest operations with > > datetimes. > > > > Note that this suggestion (and every suggestion Carl and I propose) are > > agnostic to how the data is stored in the database. That might not need > to > > change at all. All this is referring to is what the API returns. > > > > For simplicity we're designing our mock API for the Angular branch around > > the ISO 8601 format. > > >
