Do not return pointer to local from get_timezone

[skeeto]

The pointed at variable was also a wchar_t array, not char, and so also convert the contents to UTF-8. The static buffer is sized for the worst case and the conversion will always succeed.

---

I went with a static buffer because it fits the semantics of the unix version, and a similar approach is used in normalize_emoji.

[da-luce]

It would be nice if the time zone name wasn't so long. Does Windows provide a native way to obtain the abbreviated name?

[skeeto]

Hmm, looks like that information simply isn't present, and programs need their own lookup table to get abbreviations. Perhaps on Windows you could use a numeric time zone from the "Bias" field? For example, "UTC-05:00" would almost fit in that display. Or maybe just "-0500" as it appears in "git log" output.

[da-luce]

I like the idea of using the bias. To fit within the display the UTC could be dropped, so it'd just be "-05:00," much like the git log output as you mentioned.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

see 2 files with indirect coverage changes

[skeeto]

Thanks! Your program is quite fascinating and interesting. I've been poking around the code since you shared it on reddit, hence these two PRs.

[da-luce]

Thank you! I saw your fork and am really impressed with how simple you were able to get the Makefile. The Meson build is currently far more verbose than I'd like, but there are just so many weird cross-platform edge cases to handle. I'd consider moving to a Makefile like yours but that would require Windows users to have a GNU environment available (I'd also hate to give up Meson's arguably nicer syntax). CMake was originally a possibility but have only heard horror stories.

Thanks again for your PRs, and any future ideas or contributions are always welcome!

[skeeto]

I'm glad you took a look! I made those hacks just so that it's easy for me to build in general (I loathe Meson), and to hack on it on Windows. Note my changes to the README mentioning w64devkit, my streamlined Windows development kit. It's GNU in the sense that it's GCC, Binutils, and GNU Make, but the unix-like environment is busybox-w32 which, unlike MSYS2 or Cygwin, is native Windows (no POSIX layer nor virtual file system). It's a 35MB 7zip archive of "portable applications" (Windows sense) that runs in place and requires no installation, so it's painless to obtain, run, and discard. I designed it to solve exactly this sort of problem. After I removed argtable, the only sticky point that prevents a simple out-of-the-box compile after unzipping w64dk is PDCurses. As a principle, I do not distribute non-runtime libraries in w64dk, so no PDCurses (even though I statically link it into the included GDB for "-tui"). Fortunately it's a trivial build: unzip and "make -C wincon WIDE=Y UTF8=Y". I wrote a quick "ncursesw.pc" to satisfy pkg-config: Name: PDCurses Version: 3.9 Description: blah blah blah Cflags: -I${prefix}/include Libs: -L${prefix}/lib -lcurses Then copied curses.h, curspriv.h, pdcurses.a (renamed to libcurses.a), and ncursesw.pc into the w64dk sysroot at the right places, and the Makefile picks up on just like Linux and such. Linux distributions unfortunately don't provide a "curses.pc" such that one could request a generic curses implementation from pkg-config instead of something specific like ncurses, which would make this less awkward. It's a lot of steps, but once set up I can hack on it the same as as Linux. The --unicode option still doesn't work, but I believe that's a limitation of PDCurses despite "WIDE=Y" (it doesn't translate UTF-8 to UTF-16 for WriteConsoleW). My changes are quite opinionated, including the switch to a jumbo build, and so I wasn't planning on opening PRs for any more of it. It's there for my personal use.

[da-luce]

I checked out w64devkit and it's really neat! It's a bit odd Unicode isn't working for you. The precompiled binary for Windows displays Unicode correctly when I've tested on my desktop. ncurses/PDCurses seem to be super environment dependent when it comes to character support (I can't get certain Unicode characters to display on my Mac for the life of me), so it could be any number of things--but I'm not sure PDCurses is to blame in this instance.

[rmyorston]

I saw your fork and am really impressed with how simple you were able to get the Makefile.

Not only simple, also POSIX 2024 compliant!

[skeeto]

POSIX 2024 compliant

I was going to object because I used !=, but your excellent summary cleared that up!