This is the dirtiest component of going between DOM and the event abstraction (start and end times). When someone resizes the event or moves it, it's going to take some kind of pixel calculations at one point or another, even if they're very generalized, since they used their mouse to do that. This is the point at which I decided to deal with that. Otherwise the events are all handled abstractly. The data isn't necessarily coupled with the presentation, but for example the way they move the event around on the DOM when they're dragging and dropping (presentation) has to be translated into data at one point or another (and so the function is called dom2time--translating presentation to data :).

I went back and re-read your explanation above, and my constructive criticism would be the following:

1. Use a table, or horizontal grid of divs to represent the calendar. You can write different server or client side code to render different presentations, e.g. calendar, 5 day view, 7 day view etc.

2. In this grid, tag each div with the appropriate date stamp as appropriate for your application.

3. Build code on the client side to track mouse drags, clicks, or whatever you need to provide the user with a great experience specifying start and end times.

None of this sounds that hard or tricky, and I would certainly be happier with an approach that separated out generating time tagged divs from the presentation and selection mechanism.

Yeah, I did all this. :) For part 2, I still need a helper function like this because the timestamp changes (when the user resizes, moves, etc.). Does that make more sense? I have a grid of DIVs, on which I position events on top of.

EDIT: I see what you mean. For part 3, for example, I want "12:05", not "12:04:27". Yeah, I was getting to that.