Accuracy of setInterval

You say it's not pre-emptive - does that mean if I have a time-consuming function which lasts 10 seconds, setIntervals won't get called at all?

Yes, that's true. However setWatch will log input state changes using IRQs, and Waveform and digitalPulse work in similar ways too so will be unaffected.

Is there anything in the system which might cause it to block setIntervals for some largeish time period - I'm thinking bit-bang serial, I2C, CC3000.

Yes - The main offender is CC3000, which is a total disaster thanks to TI :( However if you have no active HTTP clients or servers then it should be fine.

I presume getTime() returns a value that is read directly from hardware when you call it?

Yes and no. It's based on the internal RTC, but I do some magic with SysTick that allows it to work down to 1uSec even though the RTC runs at 32/40kHz.

I see two solutions to deliver an accurate GetDateTime function which includes both calendar date and milliseconds:

Your suggestion - a global date-time variable updated every second

From the Clocks page? It's there because it's nice and easy to understand - the suggestion below is better though.

A getDT function which, when called, reads GetTime and updates a global clock variable according to time elapsed since the last time it was called.

Yes, that's probably the best bet - especially from the point of view of power saving. However, a proper implementation of Date and a value that stored how many seconds you have to subtract from getTime() to get to 1 Jan 1970 would be pretty good.

If setInteval can get delayed, and I have long-ish functions, then I suspect I need to use #2. The problem is that so far I can't duplicate a problem case :)

I'd use #2 anyway - or my #3. Please don't let functions run for over a second though - it makes me sad :) In pretty much all cases there are ways to work around it, and Espruino will work a lot better.