Ed Davies wrote on 2003-05-27 13:56 UTC: > Slightly more relevantly: I was a bit surprised that you did not > put more emphasis on the need to distinguish the different types > of time scales an application program can ask for from an operating > system, as your ctime library highlights.
Markus Kuhn replied: > I had thought about this, but I concluded that this would be out of the > scope of the ITU-R, who are in the business of standardizing time signal > broadcasts, and not operating system APIs. Fair point, but if I might summarise what I think is a slightly generalised version of your argument: 1. There's no single perfect timescale for all application requirement combinations (keeps close to UT1, SI seconds, 86 400 second days, etc) - because some combinations of requirements are contradictory. 2. We need to make up timescales for specific combinations of requirements not catered for by existing timescales (e.g., UTS if you are willing to relax the SI second requirement but don't want to use UT1 for sensible reasons). 3. We have to live with lots of timescales - please fix the radio signals to make this easier. You cover points 2 and 3 well but I think rather assume point 1 which is a pity as you are in a good position to illustrate it. If this point was already well understood then perhaps there wouldn't be the same pressure to "fix" UTC in the forlorn hope of somehow making it perfect. Ed.
