Paul Eggert wrote:
'some' end consumers do Yes, absolutely. We're trying to come up with a solution that caters to the few consumers who really need to know what time it was in Ft. Liard during the solar eclipse of June 10, 1964, without unduly burdening the far greater number of consumers who who don't want to be burdened with information that makes it more of a pain to select TZ settings and that can hurt runtime performance.
But what about the mass market example I gave?
Any application which displays historic data via a timeline ( how far does facebook go back? ) and is switched to use the new way of handling local time will have a problem when scrolling back in time if the calendar displays 'simple GMT times' in one and 'proper local time' in another ... If the BROWSER local time zone management is switched to use TZ data properly, then there is a real chance that a lot more people will be hitting historic material via that setting. Currently we have to manually manage local time zone because the browser data is incorrect, and are not using TZ to do it much of the time. With the proposed use in browsers then that will change. Where we have been using TZ for historic calendars and timelines, it's been more by luck than judgement that it's been working at all :(
-- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk