Added Area-Library, Library-Async, Triaged labels.

Removed Type-Defect, Priority-Unassigned labels.
Added Type-Enhancement, Priority-Medium labels.

This comment was originally written by @seaneagan

Looks like there is a more canonical terminology for this:

http://en.wikipedia.org/wiki/Isochronous

i.e. correctDrift -> isochronous

or could add a Stream.isochronous constructor

This comment was originally written by @jtmcdole

I used Isochronous when adding to Quiver, but no one liked it, hence Metronome:
https://github.com/google/quiver-dart/blob/master/lib/src/async/metronome.dart

The VM periodic timer is actually attempting to be isochronous.

A problem with timers in any single-threaded system is that the execution can be delayed if something else is already running or scheduled in the event queue when the timer triggers.
The timer event is usually just run as soon as possible.

A problem with an isochronous timer is what it should do if the previous task plus its delay takes more time than the interval. Or if accumulated delay adds up to more than one time the interval: should two events then be run immediately after each other.
It means that the delay between two consecutive timer triggers can can be anything from 0ms to infinity.

The JavaScript setInterval timers are defined to only start a new interval when the previous one is done executing. That means that the time between two timer triggers is always greater than or equal to the interval - which is actually more promise than the isochronous timer can give. However, it will almost certainly accumulate clock skew, even if it has perfect timers, because it's delayed by its own execution time. Any further delay from already executing events will just add to that.
That's the timer that dart2js code is using, since it's what they have.

Timer.periodic is described only loosely because it has to cover both behaviors.
All we promise is that you get at most n events in n*duration time. You can get less.