MSYS can't handle timezones in localized versions of Windows.
Steps to reproduce:
1. Do not set the TZ environment variable anywhere.
2. Start MSYS under a non-English Windows with a non-English timezone set.
3. Run the attached testing program.
4. Check that it reports a localized timezone name, such as "Horário brasileiro de verão" (Brazilian summer time).
5. Check that the date command reports wrong time with GTM timezone instead of yours.
6. Start MSYS under an English version of Windows, but using the same non-English timezone.
7. Run the attached testing program.
8. Check that it reports an English timezone name, such as "E. South America Daylight Time".
9. Check that the date command reports correct time with expected timezone, such as ESADT (which seems to be equivalent to BRST in tzinfo).
Commands such as date or ls, and MSYS/MinGW as a whole, should report at least correct time, and preferably an identifiable timezone name, such as ESADT, BRST etc.
MSYS uses GetTimeZoneInformation from Windows API to identify system timezone, and seems to compress returned name into an acronym, that being the reason we see ESADT in date for the "E. South America Daylight Time" returned by the attached program. For some reason that fails for "Horário brasileiro de verão" (maybe because there's only one uppercase letter, but even so "HBV" is not a sane abbreviation), then defaulting to GMT.
Suggestions for fixing:
1. Somehow get a language-independent timezone identification from Windows API,
possibly an abbreviation, which would avoid localized names from defaulting to GMT as suspected.
2. Ignore name failure and use some unknown timezone abbreviation, and display correct time
3. Use the tzinfo database instead of Windows API, possibly asking users for selecting
their timezones in mingw-get setup, if not possible to identify automatically
(glibc docs mention support for a timezone database but not sure if that's tzinfo, neither why
why MSYS version of glibc seems to simply lack that mentioned support).
4. Take a look a current Cygwin's code to check how they handle it these days.
The mailing list thread below is what inspired this bug report. It may be a bit difficult to read due to too much context lines, sorry, but it documents details on this issue (sorry I can't find a link from the very first post):