timer() behavior?

[kwonoj]

I tried simple timer comparison as below,

Rx.Observable.timer(0,1000).skip(5).take(1).timeInterval().subscribe(console.log);
Rx.Observable.timer(5000).timeInterval().subscribe(console.log);

RxOld

{ value: 0, interval: 5001 }
{ value: 5, interval: 5008 }

RxNew

{ value: 5, interval: 5002 }
{ value: 0, interval: 5005 }

could see emitting order is opposite between two implementation.

This causes interesting behavior differences in skipUntil operator, such as

var now = Date.now();
Rx.Observable.timer(0, 1000).do(function(){
  console.log('source : ' + (Date.now() - now));
})
  .skipUntil(Rx.Observable.timer(5000).do(function() {console.log('skip ' + (Date.now() - now)); }))
  .take(2).subscribe(console.log);

RxOld

source : 18
source : 1004
source : 2002
source : 3002
source : 4002
source : 5003
skip 5005
source : 6002
6
source : 7003
7

RxNew

source : 4
source : 1004
source : 2005
source : 3005
source : 4005
skip 5003
source : 5006
5
source : 6006
6

that RxJS4 omit source 5, new implementation does emit since parameter observable emits prior to source emitting element, diagramwise supposed to emit 'same time' and expect source does not emit as below.

  var e1 =       '--a--b--c--d--e--|'
  var skip =     '-----------x----|'
  var expected = '--------------e--|'

Bit uncertain if this need to be treated as bug though, creating issue to get some clarification I'm possibly missing. skipUntil example was taken from document, and behavior occurred on 2 systems. (windows + linux).

[benlesh]

It's likely because the default scheduler implementations are different. RxJS 5 is using recursive scheduling and setTimeout by default.

[benlesh]

Also, with these sorts of things, just the latency of the code triggering the setTimeouts can cost a millisecond here or there. I don't think anyone can or should try to rely on consistent timing from scheduling over setTimeout in two different code bases (or in some cases even within the same code base).

[benlesh]

I would be more concerned if this was the case on the VirtualScheduler or TestScheduler. But even then, as long as it's consistent within all calls from the same library, it's probably not an issue.

[kwonoj]

Got point and agreed. Just a reference, TestScheduler didn't had same issues with same example. Maybe can close issue?

[benlesh]

I'd close it. But I'll leave that to you, if you're satisfied.

[kwonoj]

I also think it can be closed - closing myself :)