16 ms·

The core issue is that tzdata files do not contain the time zone identifier. If you are unlucky in /etc/localtime is not a symbolic link, you have to scan the f

The core issue is that tzdata files do not contain the time zone identifier. If you are unlucky in /etc/localtime is not a symbolic link, you have to scan the files in /usr/share/zoneinfo to find a match. PostgreSQL prefers shorter names: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=e3846a00c2f87402dcedf7f07950ab2d89cf5827 https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit... That's why "US" wins over "America".

azinman2 1y ago
Looking at that code I’m shocked that Postgres allows two-liner if statements without a matching {} (I’m sure someone pedantically will point out that I’m using the wrong terminology or that it was actually several lines of conditionals). This practice is very bug prone, and has lead to high profile failures like goto fail
- yencabulator 1y ago
  The project history goes back to 1982. There may have been rewrites in the later 80s, but it's some of the oldest C around, and a very conservative codebase (e.g. Linux kernel gets much more aggressive refactorings regularly). That particular git repository has history imported from 1996 onward, but Postgres was a very established project by then: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=d31084e9d1118b25fd16580d9d8c2924b5740dff https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit... These days people might not blink an eye at gofmt/rustfmt rewriting the AST to clean it up, but those toolchains were built that way largley because automating anything about large C codebases is so hard.
  - azinman2 1y ago
    Except this was new code.
    - yencabulator 1y ago
      Generally, large C projects have their own style that is followed whether the code is new or not.
      - azinman2 1y ago
        And thus it’s surprising to me they haven’t changed their style moving forward when it’s known that this is error prone.
        yencabulator 1y ago
        Large stable projects are very much wary of wide-scale changes their codebase. What they have is tested working by decades in production. Especially with C where tooling is brittle. Let me put this way: If you submit a code prettifying patch to the Linux kernel, it will not be accepted. The risks aren't worth it. The only real way forward is full migration away from C, for which a better scope is a separate project.
- machinate 1y ago
  What issue are you taking with the code? Line breaks in the condition? Presumably the last if statement in the diff.
  - azinman2 1y ago
    There aren’t {} brackets after the if
    - machinate 1y ago
      Are you saying they should always be present? Or only when the condition takes multiple lines; i.e. do you take issue with the ifs in zone_name_pref too? Personally I think the indentation does a good enough job here.
      - azinman2 1y ago
        Yes I’m saying they should always be present. It is known to otherwise be error prone, which is why new c-like languages do not permit this (eg go) nor do many style guides (https://google.github.io/styleguide/cppguide.html#Formatting_Looping_Branching https://google.github.io/styleguide/cppguide.html#Formatting...)
- fweimer 1y ago
  These days, there are compiler diagnostics for that. There's also a pgindent tool, which will align the visual presentation of the code with its syntactic structure.

azinman2 1y ago

Looking at that code I’m shocked that Postgres allows two-liner if statements without a matching {} (I’m sure someone pedantically will point out that I’m using the wrong terminology or that it was actually several lines of conditionals). This practice is very bug prone, and has lead to high profile failures like goto fail

yencabulator 1y ago
The project history goes back to 1982. There may have been rewrites in the later 80s, but it's some of the oldest C around, and a very conservative codebase (e.g. Linux kernel gets much more aggressive refactorings regularly). That particular git repository has history imported from 1996 onward, but Postgres was a very established project by then: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=d31084e9d1118b25fd16580d9d8c2924b5740dff https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit... These days people might not blink an eye at gofmt/rustfmt rewriting the AST to clean it up, but those toolchains were built that way largley because automating anything about large C codebases is so hard.
- azinman2 1y ago
  Except this was new code.
  - yencabulator 1y ago
    Generally, large C projects have their own style that is followed whether the code is new or not.
    - azinman2 1y ago
      And thus it’s surprising to me they haven’t changed their style moving forward when it’s known that this is error prone.
      - yencabulator 1y ago
        Large stable projects are very much wary of wide-scale changes their codebase. What they have is tested working by decades in production. Especially with C where tooling is brittle. Let me put this way: If you submit a code prettifying patch to the Linux kernel, it will not be accepted. The risks aren't worth it. The only real way forward is full migration away from C, for which a better scope is a separate project.
machinate 1y ago
What issue are you taking with the code? Line breaks in the condition? Presumably the last if statement in the diff.
- azinman2 1y ago
  There aren’t {} brackets after the if
  - machinate 1y ago
    Are you saying they should always be present? Or only when the condition takes multiple lines; i.e. do you take issue with the ifs in zone_name_pref too? Personally I think the indentation does a good enough job here.
    - azinman2 1y ago
      Yes I’m saying they should always be present. It is known to otherwise be error prone, which is why new c-like languages do not permit this (eg go) nor do many style guides (https://google.github.io/styleguide/cppguide.html#Formatting_Looping_Branching https://google.github.io/styleguide/cppguide.html#Formatting...)
fweimer 1y ago
These days, there are compiler diagnostics for that. There's also a pgindent tool, which will align the visual presentation of the code with its syntactic structure.