Re: what shall we do with the drunken time_t ?

On 05/03/2017 07:26 AM, Michael Haubenwallner wrote: Would it be worth to override mktime() even for glibc? I doubt it for that particular issue, as the problem is due more to mktime's spec than to its implementation. I followed up at .

Re: what shall we do with the drunken time_t ?

Hi, On 04/25/2017 12:40 AM, Bruno Haible wrote: > > Opinions? > $subject rings a different bell here, with glibc: https://sourceware.org/bugzilla/show_bug.cgi?id=17646 Would it be worth to override mktime() even for glibc? /haubi/

Re: what shall we do with the drunken time_t ?

As a first step, let me document this for the POSIX functions. 2017-04-30 Bruno Haible Document the problem with the Cygwin environment variable TZ. * doc/posix-functions/tzset.texi: Add note about TZ. * doc/posix-functions/ctime.texi: Likewise. * doc/posix-fun

Re: what shall we do with the drunken time_t ?

> - the Microsoft CRT interprets TZ, but with a different expected syntax > [2][3], > which led to tzname[0] = "Eur", tzname[1] = "ope". The TZ environment variable affects a lot of C library functions: * Some which should not be exhibiting locale dependent behaviour at all: fstat, _fst

Re: what shall we do with the drunken time_t ?

I had written: > Results === > (I am in CEST, i.e. GMT+1 with DST since end of March.) > > A file last touched on 2016-11-27 18:32 GMT: > $ ls -l t.tar > -rw-r--r-- 1 bruno None 10240 Nov 27 19:32 t.tar > > Cygwin: > mtime = 17132 18 1920 >

Re: what shall we do with the drunken time_t ?

Hi Paul, > > if we want a sane behaviour, we have no choice than to override stat() > > and fstat() > > What a pain. Would it be limited to just those two? For example, is there a > system call like utimensat that lets you set a file's timestamps? It's the *utimens* test failures that brought u

Re: what shall we do with the drunken time_t ?

Bruno Haible wrote: if we want a sane behaviour, we have no choice than to override stat() and fstat() What a pain. Would it be limited to just those two? For example, is there a system call like utimensat that lets you set a file's timestamps?

Re: what shall we do with the drunken time_t ?

Hi Paul, > Your latest message prompted me to search microsoft.com further, and I > found this: > > https://support.microsoft.com/en-us/help/190315 Excellent finding! Thank you. > I wonder whether Cygwin deals with this problem? Cygwin's stat() implementation converts the times (from FILETIME

Re: what shall we do with the drunken time_t ?

On 04/25/2017 12:09 PM, Bruno Haible wrote: Emacs also appears to not use st_mtime of opened files (at least not by default). But if it warned the user about files modified in the background (like Nodepad++ and KDE kate do), it would exhibit the same symptom. Your latest message prompted me to

Re: what shall we do with the drunken time_t ?

Hi Paul, > Couldn't asctime be causing the problem, insted of stat, gmtime etc.? No, the problem is really with stat(). In my test program I had decomposed the time_t into days, hours, seconds myself: int day = tt / (24*3600); int hour = (tt / 3600) % 24; int seconds = tt

Re: what shall we do with the drunken time_t ?

Couldn't asctime be causing the problem, insted of stat, gmtime etc.? The Microsoft documentation for asctime says that it adjusts its output according to local time zone settings, a behavior that disagrees with POSIX. This could explain the symptoms you're seeing. https://msdn.microsoft.com/e

what shall we do with the drunken time_t ?

Hi Paul, all, I'm trying to port utimens and futimens to native Windows. A major problem is the semantic of time_t on native Windows. An experiment (at the end of this mail) shows that: * While on POSIX systems, time_t is the number of seconds since 1970-01-01 00:00:00 UTC/GMT [1][2], on native