Futuristic GETSTAMP

rocatis

f:file
d:date
t:time

---

f.CREATE('c:\test');
f.close;

getstamp('c:\test',d,t);

MESSAGE('%1\%2',
format(CURRENTDATETIME,0,'<Hours,2>:<Minutes,2>:<Seconds,2>:<Thousands,3>'),
format(CREATEDATETIME(d,t),0,'<Hours,2>:<Minutes,2>:<Seconds,2>:<Thousands,3>'));

---

If you run this you will find that the file is always created in the future... Okay, so it's only between half a second and two seconds, but it's in the future nonetheless.

Any brilliant minds out there that can explain this?

ara3n

I ran it in 2013 and the results are

09:38:23:283
09:38:23:279


Looks fine to me on rtc.

rocatis

ara3n wrote:

I ran it in 2013 and the results are

09:38:23:283
09:38:23:279


Looks fine to me on rtc.

Well, ain't that just great... So GETSTAMP works correctly in RTC but is off by 0,5 to 2 seconds in Classic. That makes absolutely no sense whatsoever.

I'm getting too old for this shit :roll:

ara3n

It's a good reason to upgrade.

rocatis

ara3n wrote:

It's a good reason to upgrade.

Hehe. Actually, I think it's a pretty poor reason to upgrade 8)

ara3n

I was being sarcastic. You can submit contact MS for a fix.

vaprog

What is the granularity of whatever timestamp GETSTAMP returns on the filesystem you are writing to / reading from?

(And to be pedantic: the date returned is undefined because you never wrote anything to the file:

GETSTAMP Function (File)

Use this function to find out exactly when a file was last written to (return a timestamp).

)

On NTFS with NAV 2009 R2 Classic I get

17:12:35:227
17:12:36:000

rocatis

vaprog wrote:

What is the granularity of whatever timestamp GETSTAMP returns on the filesystem you are writing to / reading from?

Not sure what you mean here, but the problem exists for all files, whether they're empty or not or have been created by NAV or not.

Use GETSTAMP on any file on your system and you will get a wrong time (compared to what the file properties window will tell you in Explorer). It's just a bit hard to see because the time stamp in Explorer is only shown down to the second.

vaprog wrote:

And to be pedantic: the date returned is undefined because you never wrote anything to the file:

No. Creating a file also sets the modified date/time.

vaprog wrote:

On NTFS with NAV 2009 R2 Classic I get

17:12:35:227
17:12:36:000

The file is still modified in the future.. Did you run the test multiple times? And if so, was the displacement the same every time? I could sort of accept it if the time stamp was just rounded up to the nearest second, but that's not the case either I just did a couple of tests:

17:50:34:021
17:50:36:000

17:50:56:816
17:50:58:000

It's never more than 2 seconds though :-k

vaprog

rocatis wrote:

vaprog wrote:

What is the granularity of whatever timestamp GETSTAMP returns on the filesystem you are writing to / reading from?

Not sure what you mean here, but the problem exists for all files, whether they're empty or not or have been created by NAV or not.

With granularity I meant the precision with which the date is recorded in the file system. See File Times on msdn for some more info. Whether the file is empty or not is irrelevant for this statement of mine. That statement was given in a new paragraph and in parenthesis.

rocatis wrote:

vaprog wrote:

And to be pedantic: the date returned is undefined because you never wrote anything to the file:

No. Creating a file also sets the modified date/time.

You are assuming that GETSTAMP returns the modified date of the file. But that is not what the documentation of that function says. It does not deny it either. The documentation in the C/SIDE help and on msdn says:

Use this function to find out exactly when a file was last written to (return a timestamp).

(emphasis mine) GETSTAMP Function (File) - MSDN - Microsoft.
And I said I was being pedantic - to the documentation, that is. The statement was meant to make you think about your expectation in the light of what is promised to you (i.e. documented) concerning this function. Note: nothing is said about the precision of the returned timestamp.

rocatis wrote:

The file is still modified in the future.

According to GETSTAMP, that is. I didn't claim anything different.

rocatis wrote:

Did you run the test multiple times? And if so, was the displacement the same every time? I could sort of accept it if the time stamp was just rounded up to the nearest second, but that's not the case either I just did a couple of tests:

To me it looks like the timestamp is rounded to the next even second (Like or similar to the FAT file system).

rocatis

vaprog wrote:

With granularity I meant the precision with which the date is recorded in the file system. See File Times on msdn for some more info.

You make the suggestion that the granularity is 2 seconds ("To me it looks like the timestamp is rounded to the next even second"). That's 100% consistent with the results when running the test script.

Interestingly enough, the "File Times" link you provided says "For example, the resolution of create time on FAT is 10 milliseconds, while write time has a resolution of 2 seconds". But we're not using FAT, and if you view the properties of a file in Explorer the granularity is (at least) 1 second.

Also, doing the test using NAV 2013 tells us that the granularity here is 1/1000s.

My guess is that the GETSTAMP function was rewritten/updated in NAV 2013 to show the actual date/time stamp of the file whereas the function in earlier versions were written to adhere to the way FAT works. This would make sense insofar as NAV was born from FAT - so to speak.

Even so I still think it's weird that the time is rounded up and not down.

Use this function to find out exactly when a file was last written to (return a timestamp).(emphasis mine)

Yes, but that's not what the function does. It doesn't make sense that "Last written to" can be in the future (now I'm being pedantic, I know).

I think we're in agreement.