Dave Rolsky wrote: >This is actually more bizarre then just having a leading colon, I think.
As previously mentioned, a leading colon is no good for signalling syntax. If you want to go that route, pick some other leading character to signal a native filename. Bizarreness discussed below. >It might be preferable to require an actual file URI with scheme >(file:///etc/local/time or file://C:\foo\bar) I pondered doing something like this. With the leading "/", it would be easy to interpret the whole string as a URI path and translate that into local syntax. Both of the examples that I gave would come out the same. The disadvantage is that things like "/a%20b" then wouldn't act like Unix filenames on Unix. URI syntax has the major advantage of being already familiar to a great many users across all OSes. "file:///c:/foo/bar" gets done on Windows, for example. For this reason I think any form of "/"-delimited syntax is not hugely strange to Windows users. By the way, I just tried, and "/c:\foo\bar" does get translated to "c:\foo\bar" by the current code, so it turns out the user doesn't have to use "/" delimitation after all. As for using a complete URI with scheme name, I see three problems. The deep problem is that users will expect us to support downloading tzfiles from arbitrary URIs of any scheme, which is not the plan. The trivial problem is that URI scheme name syntax makes URIs clash with some of the syntaxes we already support, so we'd need some other flag character in front of the URI. Finally, you're talking about inventing a completely new facility here, whereas the "/"-prefixed Unix filename is an existing widely-supported $TZ syntax. I'd like to know if there's any precedent for timezone setting by filename on Mac or Windows. >I'd love to hear from the original requestor, but I'd guess that they'd >prefer to use the correct modern rules, as opposed to a to-the-POSIX-spec >interpretation. The POSIX spec doesn't say what DST rules apply when they're not explicitly stated in the timezone string. Any rules at all are POSIX conformant. For this reason people should not be relying on any particular behaviour from such strings, and should be giving a full rule. The Alaskan user should be using "AKST9AKDT,M3.2.0,M11.1.0" if ey wants to go the SysV route. So I really don't care which behaviour we provide in the unspecified case. I readily defer to your judgement concerning grandfathering of these special cases. >Honestly, supporting these POSIX time zones seems of academic interest or >useful for emulating some old system's behavior, but if you're writing new >code, it doesn't seem like a good idea at all, My objective in this is merely to support all $TZ settings that the various libcs do. System V strings are an important subcase. -zefram
