Okay, thanks for the clarification. If it's by design, and not all implementations may be case-sensitive, should the installer clarify in case of a user not entering a valid timezone path that paths are case-sensitive? Right now I think it could be made a little clearer that it's looking for an exact match. I know it's not a big deal but changing the error message might make things clearer for some users.
Katherine On Sat, May 1, 2021 at 9:55 PM Theo de Raadt <dera...@openbsd.org> wrote: > > Luigi30 <luig...@gmail.com> wrote: > > > I noticed that timezone paths in the installer step that sets the system > > timezone are case-sensitive to match the paths in /usr/share/zoneinfo. > > (Specifically, it's set_timezone() in > > /usr/src/distrib/miniroot/install.sub.) > > > > It seems like the behavior should be more like: > > > > - Upon entering set_timezone(), it builds its /usr/share/zoneinfo lookup > > table and converts it to lowercase with sed. > > - User enters "America/chicago" or something for the timezone path. > > - The script converts the timezone path to lowercase with sed. > > - The script compares the lowercase path to the /usr/share/zoneinfo table. > > - If there's a match, it uses the properly capitalized path. > > > > As implemented now, the script would only confusingly reply that there > > is no such timezone as America/chicago. > > > > I started working on a fix for this but before I go tilting at windmills, > > is there a technical reason that the script behaves this way? > > Issues with internationalization? Or is it just an oversight? > > I disagree with your assessment and proposal. > > "Do not use names that differ only in case. Although the reference > implementation is case-sensitive, some other implementations are not, > and they would mishandle names differing only in case." > > Timezones are case sensitive. > > We may as well force people to correctly select the name in this > situation, because if they "learn" that lowercase is acceptable in the > installer, they may return to userland and insist that > TZ=America/chicago should work. > > % TZ=America/Chicago date > Sat May 1 21:53:50 CDT 2021 > % TZ=America/chicago date > Sun May 2 02:53:47 GMT 2021 > > As you can see, it does not work.
