bugGNU Octave - Bugs: bug #53917, Incorrect warning: time stamp for...


bug #53917: Incorrect warning: time stamp for 'filename' is in the future

Submitted by:  Ian McCallion <ianmcc>
Submitted on:  Tue 15 May 2018 08:18:15 PM UTC  
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Unexpected Error
Status:  Works For Me Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  4.4.0 Operating System:  Microsoft Windows

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Fri 25 May 2018 05:07:53 PM UTC, comment #8:

Ok, if this ever returns we have a good start at debugging it here.

Mike Miller <mtmiller>
Project Administrator
Mon 21 May 2018 06:45:18 PM UTC, comment #7:

Well the problem STILL does not show with my original script.

I can only assume it was a glitch that persisted for a day or so and was cured when I rebooted the system.

If there is an actual Octave bug causing the problem it is very obscure and probably of no significance.

Ian McCallion <ianmcc>
Mon 21 May 2018 05:50:46 PM UTC, comment #6:

Duhhh yes! I had tried with a script, but not with an actual function file.

Now to remember what I was going to try out!

Ian McCallion <ianmcc>
Mon 21 May 2018 05:45:21 PM UTC, comment #5:

Ian - if you remember, you said that dummy.m must be a valid Octave function file. In the output you show here it looks like dummy.m is an empty file. Is that the reason you are not getting the warning now?

Mike Miller <mtmiller>
Project Administrator
Mon 21 May 2018 05:30:41 PM UTC, comment #4:

I have tried to do some more work on this, but when rerunning my original scripts the error was not occurring. Even more peculiarly, I am now unable to provoke the warning message even when the script file timestamp is a year in the future as shown in this console log:

Hence I am at this point unable to do more experiments to further this bug discussion.

I am unaware that I have made any changes to Octave between the time of my original post and now. I get exactly the same behaviour on 4.2.2

Ian McCallion <ianmcc>
Fri 18 May 2018 05:29:11 PM UTC, comment #3:

What I can interpret from this so far is that the Windows function call GetFileInformationByHandle is returning a BY_HANDLE_FILE_INFORMATION structure that contains a ftLastWriteTime time stamp that is in the future.

According to what I have read, this time stamp should be in UTC regardless of the time zone setting if the file system is NTFS. But you are seeing a time stamp that is in the future.

I can't explain or assume any further than that, maybe someone will have to write an oct file that uses the Windows API functions directly to see what the time stamp is after the 'touch' command completes. And whether the time stamp continues to change as the TZ environment variable is changed.

Mike Miller <mtmiller>
Project Administrator
Fri 18 May 2018 12:54:20 PM UTC, comment #2:

I can confirm that adding those two lines the mtime field is larger, by the expected amount for the timezone shift.

Ian McCallion <ianmcc>
Tue 15 May 2018 10:27:35 PM UTC, comment #1:

Can you add the following

after the pause, and show the output?

If I'm following the code correctly, the time stamp shown in the 'mtime' field of 'out' should be larger than the value of 'tnow' for this warning to be printed.

Mike Miller <mtmiller>
Project Administrator
Tue 15 May 2018 08:18:15 PM UTC, original submission:

The script below shows an unwanted interaction between using TZ for the purposes of the application and Octave's inappropriate dependency on the current value of of TZ in monitoring the Octave path for changed files. (Caveat. I'm on windows)
Before launching this script, create a valid do-nothing function called dummy.m. An empty file does not show the problem

I am using Windows 10. The file is on a hard disk formatted NTFS. The touch command sets the filetime correctly to the current time yet the output of the script is:

Ian McCallion <ianmcc>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by ianmcc (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-05-25 mtmiller StatusNeed Info => Works For Me
        Open/ClosedOpen => Closed
    2018-05-15 mtmiller StatusNone => Need Info

    Back to the top

    Powered by Savane 3.4