#482 time reports the wrong date (when run through cygwin)

[DanielAjoy]

Hi

right now I'm using Version 6.35 wxWidgets

I'm also using "cygwin"

Today is:

date
Mon, Oct 31, 2016 7:04:36 PM

I have a time.lgo file that says:

show time

I type:

/cygdrive/c/sm/FMSLogo/fmslogo -L time.lgo

[Tue Nov 01 01:04:37 2016]

I was expecting FMSLogo to show me the same date as the date command of the system.

This is not a problem when I open Window's CMD and type:

c:\sm\FMSLogo\fmslogo.exe -L time.lgo

I get:

[Mon Oct 31 01:05:30 2016]

[David Costanzo]

For some reason, I always thought you lived in Spain, but I guess you live in central america.

It's not wxWidgets that's messing things up, but gcc's libc, which the wxWidgets version is compiled with (as opposed to Borland's libc, which the OWL version is compiled with). FMSlogo calls time() to get the time-zone independent time, then calls ctime() to format it. ctime() is supposed to "know" your time zone and adjust the time to it before formatting it, but for reasons I haven't investigated, it doesn't when run from cywin's bash (which is weird, because if anything should play well with libc, it's cygwin).

I expect that the time before your edit (in GMT) is what FMSLogo really returned (as Nov 1).

To work around this in the short-term, you can run this before running FMSLogo

unset TZ

[DanielAjoy]

Ecuador. GMT -5

unset TZ

Thanks that worked.

[David Costanzo]

I have investigated the behavior of ctime(). From the GNU libc documentation

If characters begins with a slash, it is an absolute file name; otherwise the library looks for the file /usr/share/zoneinfo/characters.

However, fmslogo.exe is compiled with mingw-w64-g++. I pass the compiler flags to use a static libc, which I assumed would be GNU's libc, since mingw-w64-g++ is part of the GNU toolchain, but it actually forwards the calls to Microsoft's C runtime, at least for calls to ctime(). This calls _tzset() to get the time zone.

From the MSDN documentation for _tzset

set TZ=tzn[+ | –]hh[:mm[:ss] ][dzn]

The specifics aren't important, only that Microsoft's ctime() expecting TZ to be string like "GST-1GDT", not a filename.

In short, I think both implementations of the C runtime are justified in providing a way to override the operating system's time zone. I think cygwin is doing the right thing by setting TZ according to GNU/POSIX expectations. I also think that mingw-w64-g++ is doing the right thing by using a Microsoft-specific function for getting the timezone, since it cannot assume that /usr/share/zoneinfo exists and timezone information (particularly Daylight Savings Time) is hard to get right and changes from year-to-year (based on legislation). It's better let the someone else keep it up-to-date.

It's unfortunate that the two implementations clash, but my judgement is that this is a bug in FMSLogo. Just because ctime() changes depending on "TZ" doesn't mean that TIME, should too. I wasn't able to find a better alternative to ctime(), so I patched FMSLogo to do roughly what I recommended that you do: it unsets "TZ" before calling ctime(), then restores it afterward. Restoring it is important so that, if you run SHELL, the child program will have the same TZ that the parent environment had. That is, if you run FMSLogo from bash in cygwin, you run TIME, then you run SHELL to run another cygwin program, the child cygwin program will use the TZ from your bash environment.

The fix will be available in FMSLogo 7.0.