Consider adding $date as built-in service.

[jgrund]

I know this is trivial to add as a new factory, but why is there not a $date service available, a-la $window?

[petebacondarwin]

What would it do?

On 18 February 2013 16:50, Joe Grund notifications@github.com wrote:

I know this is trivial to add as a new factory, but why is there not a
$date service available, a-la $window?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2030.

[jgrund]

The same thing as $window basically. Act as a simple wrapper to ease mocking / stubbing during tests.

[petebacondarwin]

But a wrapper around what? $window is a global singleton.
There is no singleton Date. You create dates using new Date()...
Am I missing something?

On 18 February 2013 18:06, Joe Grund notifications@github.com wrote:

The same thing as $window basically. Act as a simple wrapper to ease
mocking / stubbing during tests.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2030#issuecomment-13734834.

[jgrund]

I was thinking of wrapping the Date constructor function itself. i.e. :

angular.module('someModule').factory('$Date', function () {
   return Date;
});

Then in a unit test you could do:

describe('testing a service that uses $Date', function () {
  var value = 1361214184148;

  beforeEach(module(function($provide) {
    $provide.decorator('$Date', function ($delegate) {
        spyOn($delegate.prototype, 'valueOf').andReturn(value);
        return $delegate;
      });
  })
});

Now later on in your tests, you can be sure that valueOf will return the value you have specified.

Granted, this could be done without without wrapping the Date constructor in a module; and I think your larger point is that $window returns an instance while $Date would return a constructor.

If this is the case, then would the recommended approach be to not wrap Date at all and just spy / mock on the global object directly?

[emhagman]

Why not implement something like http://arshaw.com/xdate/ into Angular? This way the $date service actually handles parsing, formatting, etc.

[cburgdorf]

I assume there is nothing internally that relies on Date hence no need to put it into the core. It's sure useful for others but more as a separate module.

[emhagman]

Very true, valid point.

[stefaneg]

The built-in date filter does not rely on Date? Nevertheless, this is an issue most TDD novices stumble on, how to test code which relies on current date/time, so I would think it would be worthwhile to provide a standard way to inject a factory which at least provides the current date/time. I think this is something I've done in almost every project I've touched upon for the last 10 years or so, to create my own interface which returns the current date/time. And I'm adding one today to my first angular project...

[cburgdorf]

You are right, I didn't think about the Date filter. Indeed it relies on date and makes hard use of it:

https://github.com/angular/angular.js/blob/master/src/ng/filter/filters.js#L355

With this in mind, I would also vote for creating a wrapper service for easier testing.

[petebacondarwin]

If you are testing stuff that relies on the dateFilter you could simply mock that out. I don't think that Date is used enough in the core to warrant a wrapper service.

Moreover, I think that having date related stuff in AngularJS core was a bad design choice, since there are some many possible facets to it. I would suggest that someone creates a new AngularJS module that provides comprehensive date tools (services, filters, directives, etc) that people can choose to include in there apps as required, rather than bloating the core with more functionality.

[wilsonjackson]

What seems like a no-brainer to me is exposing the date parsing logic currently contained in the date filter as a built-in service. There is poor browser support for parsing ISO-8601 dates, and currently anyone writing an AngularJS app has to polyfill that simple behavior themselves, when it's already sitting there in Angular core, just out of reach. Is it improper to suggest that here — should I open another issue?

[chiester]

@jgrund I'm doing what you proposed above except I'm using moment.js and using a service to return moment so that I can mock that service in my tests.

[larschri]

Another thing to consider in a $date service is to freeze the time during an angular digest operation. This would be useful to avoid extra digest cycles caused by code that depends on new Date(). I think that would be a very useful feature, and it would be a reasonable "best practice" to obtain current time from this service.

The system time is an essential external dependency and it would be very nice if all angular code used a common $date service that could be mocked just as easy as $http.

edit: wait.. maybe the service I'm talking about is $now, not $date.