As I mentioned below, the sample chart is very choppy on IE8 (although it's wonderful on Safari, FF and Chrome).
The error bars and the ability to adjust the moving average "period" are pretty useful features for some specific use cases, and I haven't seen these in other similar libraries.
An interface suggestion for you or Dan: make zoom in/out more discoverable. I've used other packages with this style of zoom interface, so I know there's precedent and some people will figure it out. But newcomers will be lost.
 As an addendum, it's nice to see this library hosted on github where myself and others have a chance to easily contribute changes and patches, mix/match/etc each others forks and such. I really wanted to see changes and contributions to the Flot library flow a bit faster (eg: there's a bug in series drop shadows that's had a patch on the mailing list for over a month with no interest from the maintainers in fixing it). I've asked the project owners if they'd be willing to move from Google Code to github to allow for more this, but got a reply implying that most users of Flot are not sophisticated enough to contribute. Darn..
Functional communities can and do exist without Github. In fact, I find patch review on maillists to still be a lot easier than on most of the new DVCS-centric hosting sites.
Also, perhaps the best thing is to be less shy about offering patches? I've had pretty good luck with just spamming someone with my patches and saying "here you go, thought you might like this." Some don't ever provide feedback or take the patch, but those are far and away the exception to the rule.
If the upstream owner doesn't accept patches the project is hosed, regardless of how it's hosted.
The big difference with a DVCS is that those chaotic forks are public and can themselves accept patches. Developers can still pool their bug fixes, added features, etc., and perhaps the project can rise from the ashes.
If the project is hosted on a centralized VCS, all of those bug fixes and new features languish as one-off forks in private repositories. Instead of being a chaotic mess, it's moribund. You still have the same issue of having to maintain your own fork; you just don't have any help in doing so.
This is exactly my sentiment. There's been over the last two years an occasional sense that the Flot guys have held the project hostage in some ways because for a long time it was the only viable library that did things the "jQuery way" with a sufficient number of fixes to remain stable on IE.
Late into the project (where they stand now), it sucks to see important patches languish because the maintainers aren't vigilant or have more important things to attend to. The fact remains, visualization is now a fairly important component for a fair number of people who are working on data/analytics applications. It's easy for people to bandy about anecdotes of other projects or maintainers which do well on mailing lists and non-DVCSes .. but in this case it's not working terribly well for the Flot guys.
So technical merits aside, this is why people might wander away from Flot and to projects like Dygraphs, beta warts and all, all because of issues not relating directly to code. Github may not be a panacea but when you see people like John Resig saying stuff like "I'm loving the influx of new contributors to jQuery core since moving to Github.", it must mean they're doing something incrementally better :)
It's time for project owners to ease up on the reigns a bit, and I'm pleased to see more and more interesting projects hosted on github for this reason.
If you click on some of the links under "Gallery", you'll see that they do work in IE6. The main documentation page is particularly difficult to render, since it contains so many Dygraphs.
A time series example - http://people.iola.dk/olau/flot/examples/time.html
What are the competing libraries, and how do they compare?
We use it in our metrics site. Doesn't look quite as nice as this, and we had to hack in zooming / drag range selection and a few other things.
I'm certainly interested in evaluating replacing it with this.
The biggest thing we have with Timeplot that I don't see here are event markers. On the demo page linked above, if you click on one of those pink areas, you'll get a little popout that you can use to display useful information about a particular event point or range.
it bring IE8 completely to its knees.
thx for the docs!! (i'm also using g.raphaeljs.com for pie and dot charts....could definitely use some docs there)
a couple features that would be cool, in order of priority:
* log scale
* date format
* pan (and more obvious zoom controls. cursor changes to pointer over graph...still not clear how to zoom out, though)
* more than 2 lines (right? i can't make more than 2 lines show up)
keep it up!!
* log scale: agreed, there's an open feature request for this. Feel free to star it if you want to follow along: http://code.google.com/p/dygraphs/issues/detail?id=15
* date format: You can actually do this now via the "xValueFormatter" attribute. You pass in a function to format the date. It's undocumented, though. I should fix that.
* pan: agreed, see http://code.google.com/p/dygraphs/issues/detail?id=7
* more than two lines: dygraphs can certainly do this. I've tested it with at least 7 and there's no reason it couldn't handle more.
Double clicking to zoom out took me a while to discover.
In general, though, temperatures in SF rarely go above 80. When they do, it's newsworthy.
Using a 14-day moving average makes it clearer. A 100-day rolling period averages out nearly all the specifics from the data.
You can change the moving average - it's in the bottom left corner of the graph.
The historical data presented in the graph shows more variance.