Programming with dBASE - :duflp:filestamp.cc

Author

:duflp:filestamp.cc

Bruce Beacham

2005-11-18, 8:23 pm

Hi

I am trying to work with absolute filestamp times for use in my
user-update program to get over an issue with Summer Time (or
Daylight-Saving Time).

I'm getting stuck when experimenting. Can anyone tell me why this code
fails with "Property is not accessible"? Its problem is on this line:
this.fileTime := c1
- in setFileTimeFromFileS
tamp()

Bruce

********
set proc to :duflp:filestamp.cc
fs = new filestamp()
fs.filename = "c:\program files\dbase\plus 2.60\bin\plus.ini"
? "File exists: ", file(fs.filename)
? fs.getfilestamp()

return
********

Rick Miller

2005-11-18, 8:23 pm

Bruce Beacham <bbeacham@beacham.no-spam.co.uk> wrote in
news:FlR3WlJ7FHA.1184@news-server:

> Hi
>
> I am trying to work with absolute filestamp times for use in my
> user-update program to get over an issue with Summer Time (or
> Daylight-Saving Time).
>
> I'm getting stuck when experimenting. Can anyone tell me why
> this code fails with "Property is not accessible"? Its problem
> is on this line:
> this.fileTime := c1
> - in setFileTimeFromFileS
tamp()
----

fileTime is a protected property.
setFileTimeFromFileS
tamp is a protected method.

the code is designed to use the get and set methods.

>
> ********
> set proc to :duflp:filestamp.cc
> fs = new filestamp()
> fs.filename = "c:\program files\dbase\plus 2.60\bin\plus.ini"
> ? "File exists: ", file(fs.filename)
> ? fs.getfilestamp()
----

after your lines above.
? fs.get("time") // return time
? fs.get("date") // return date

? fs.set("time", cMynewTime) // return success/fail
? fs.set("date", dMynewDate) // return success/fail
? fs.set("filestamp") // return success/fail

>
> return
> ********

Hope it helps,
Rick Miller

Bruce Beacham

2005-11-19, 3:23 am

Rick Miller wrote:

The author himself! Thanks for replying, Rick.

> fileTime is a protected property.

What I've learned from this is that this command:
protect bokay, date, fileTime, hour, message, minute,;
month, runtime, second, sysTime, year
- protects class properties that are so-named - despite the absence of a
WITH block or a "this." prefix. That wasn't so obvious late last night!

> setFileTimeFromFileS
tamp is a protected method.

Yes. I was accessing it from another method (getfilestamp()) - but
that too is protected. I'm surprised I could run it.

> the code is designed to use the get and set methods.

> after your lines above.
> ? fs.get("time") // return time
> ? fs.get("date") // return date

That gave me
00:00:00
01/01/2002

So I tried this:
set proc to :duflp:filestamp.cc
fs = new filestamp()
fs.filename = _dbwinhome + "bin\plus.ini"
? "File " + fs.filename + " exists: ", file(fs.filename)
? fs.get("filestamp")
? fs.get("time") // return time
? fs.get("date") // return date

That gave me the current date and time, not the date and time of the file.

Still stuck, I'm afraid.

Ultimately I'm trying to reach the time of a file suppressing the
effects of Daylight Saving, so always comparing files using "winter
time", or even a "winter time" that also ignores time zones. I have seen
http://msdn.microsoft.com/library/d.../file_times.asp

- which is not unhelpful.

Bruce

Ivar B. Jessen

2005-11-19, 11:23 am

On Sat, 19 Nov 2005 08:52:52 +0000, Bruce Beacham
<bbeacham@beacham.no-spam.co.uk> wrote:

>So I tried this:
>set proc to :duflp:filestamp.cc
>fs = new filestamp()
>fs.filename = _dbwinhome + "bin\plus.ini"
>? "File " + fs.filename + " exists: ", file(fs.filename)
>? fs.get("filestamp")
>? fs.get("time") // return time
>? fs.get("date") // return date
>
>That gave me the current date and time, not the date and time of the file.
>
>Still stuck, I'm afraid.

Try the code below my signature to get the three different file stamps.

Notice that Plus.ini is rewritten each time dBase is closed and that may be
why you see the current date and time.

>Ultimately I'm trying to reach the time of a file suppressing the
>effects of Daylight Saving, so always comparing files using "winter
>time", or even a "winter time" that also ignores time zones. I have seen
>http://msdn.microsoft.com/library/d.../file_times.asp
>
>- which is not unhelpful.

Thanks for the reference, it looks good.

Notice the folloing paragraph from the description of the FILETIME
structure:

"Not all file systems can record creation and last access time and not all
file systems record them in the same manner. For example, on NT FAT, create
time has a resolution of 10 milliseconds, write time has a resolution of 2
seconds, and access time has a resolution of 1 day (really, the access
date). On NTFS, access time has a resolution of 1 hour. Therefore, the
GetFileTime function may not return the same file time information set
using the SetFileTime function. Furthermore, FAT records times on disk in
local time. However, NTFS records times on disk in UTC. For more
information, see File Times."

Your problem should be solved by saving all files on NTFS ;-)

( I have one disk with NTFS and several with FAT. When copying a file from
NTFS to FAT I did not see any difference in times or any hours displayed in
AccessDate. Maybe it is necessary to use the API functions mentioned in the
article to get better results than with the FileSystemObject )

Ivar B. Jessen

//-----
function getFileTimes(cFilena
me)

// Usage: getFileTimes(_dbwinh
ome + "Bin\resource.dll")

#define OFF_SET 25

fso = new oleautoclient("Scripting.FileSystemObject")
f = fso.GetFile(cFilename)

? "Date Created: ", f.dateCreated at OFF_SET
? "Last Modified:", f.datelastModified at OFF_SET
? "Last Accessed:", f.dateLastAccessed at OFF_SET
//-----

Bruce Beacham

2005-11-19, 11:23 am

Ivar B. Jessen wrote:

> Try the code below my signature to get the three different file stamps.

Yes, thanks for that. Now I need to re-read the article to see if it's
the timestamp to use.

In fact I've this morning worked out the required procedure in the
context of my updater program: I must re-make (and propogate) the
master lists of file timestamps immediately after a clock change, and
the download program must pay no attention to the timestamp on any file
held within a zip (it is frozen at the display value which is true at
the time of saving).

> Notice that Plus.ini is rewritten each time dBase is closed and that may be
> why you see the current date and time.

Nice idea, but no, I was using that as a known fixed point that would be
easily used by testers here. I was actually running the code in a
different version, from a different directory.

> Your problem should be solved by saving all files on NTFS ;-)

Yes, I thought that too. I am reluctant to install on anything other
than XP as dBASE does seem able to find the chinks in the OS and trip
over them! So NTFS is the general experience, thank goodness.

> ( I have one disk with NTFS and several with FAT.

I did that (in partitions) on previous computers but I have now set my
data partitions all to NTFS on the basis that I won't nowadays be using
a DOS emergency disk to extract the data from them.

> When copying a file from
> NTFS to FAT I did not see any difference in times or any hours displayed in
> AccessDate. Maybe it is necessary to use the API functions mentioned in the
> article to get better results than with the FileSystemObject )

Ivar B. Jessen

2005-11-19, 1:23 pm

On Sat, 19 Nov 2005 17:07:20 +0000, Bruce Beacham
<bbeacham@beacham.no-spam.co.uk> wrote:

[color=darkred]
>
>Yes, I thought that too. I am reluctant to install on anything other
>than XP as dBASE does seem able to find the chinks in the OS and trip
>over them! So NTFS is the general experience, thank goodness.
>
>
>I did that (in partitions) on previous computers but I have now set my
>data partitions all to NTFS on the basis that I won't nowadays be using
>a DOS emergency disk to extract the data from them.
>

Small correction, there _is_ a difference between NTFS and FAT. I copied
resource.dll to a NTFS partition (C:) and to a FAT partition (J:) and ran
the following tests:

Computer date set to 19. November 2005
Files created on local time 19:39:49

Standard Daylight Time, Denmark is one hour before GMT or: GMT + 1h

getFileTimes("C:\temp\resource.dll") // NTFS
Date Created: 19-11-2005 19:39:49 GMT + 1h
Last Modified: 31-10-1999 19:41:26
Last Accessed: 19-11-2005 19:39:49

getFileTimes("J:\temp\resource.dll") // FAT
Date Created: 19-11-2005 19:27:30 GMT + 1h
Last Modified: 31-10-1999 19:41:26
Last Accessed: 19-11-2005

Computer date is set to 19 July 2006
Daylight Saving Time, Denmark is two hours before GMT or: GMT + 2h

getFileTimes("C:\temp\resource.dll") // NTFS
Date Created: 19-11-2005 20:39:49 GMT + 2h
Last Modified: 31-10-1999 20:41:26
Last Accessed: 19-11-2005 20:39:49

getFileTimes("J:\temp\resource.dll") // FAT
Date Created: 19-11-2005 19:27:30 GMT + 1h
Last Modified: 31-10-1999 19:41:26
Last Accessed: 19-11-2005

Conclusion: The file was saved at 18:39:49 GMT and when the time is read
from a NTFS partition and corrected for any offset due to timezone and
Daylight-Saving-Time it will always result in the correct GMT.

So all you need is a function to tell you the partition type, the timezone
the computer is set to and if it is Daylight Saving Time. The only problem
areas left are the hours when DST begins and ends :-)

Ivar B. Jessen

Bruce Beacham

2005-11-20, 3:23 am

Ivar B. Jessen wrote:

> Conclusion: The file was saved at 18:39:49 GMT and when the time is read
> from a NTFS partition and corrected for any offset due to timezone and
> Daylight-Saving-Time it will always result in the correct GMT.

I think that article tells us the functions to chain.

> So all you need is a function to tell you the partition type, the timezone
> the computer is set to and if it is Daylight Saving Time. The only problem
> areas left are the hours when DST begins and ends :-)

LOL!

I've always wondered how Windows knows the dates, seemingly without
recourse to the Internet.

Bruce

Ivar B. Jessen

2005-11-20, 8:23 pm

On Sun, 20 Nov 2005 08:50:56 +0000, Bruce Beacham
<bbeacham@beacham.no-spam.co.uk> wrote:

>
>I think that article tells us the functions to chain.

I did not look that far into the article. Instead I made an attempt with
readily available functions. See code below.

Save code as fileCreatedGMT.prg and use from command pane in this way,

fileCreatedGMT(_dbwi
nhome + "Bin\Resource.dll")

Note the result and copy Resource.dll to NTFS and FAT32 partitions and
check that the function always returns the same GMT timestamp. Change the
date setting in the control panel from November to July and confirm that
the returned timeStamp is unchanged.

>
>
>LOL!
>
>I've always wondered how Windows knows the dates, seemingly without
>recourse to the Internet.

Run the MS program TZEdit.exe (Windows NT Time Zone Editor) and select:

(GMT) Greewich Mean Time: Dublin .....
At the bottom of the window it says,

Daylight Saving Time
Start Date/Time: Last Sunday of March at 01:00:00
End Date/TIme: Last Sunday of October at 02:00:00

For the next time zone (GMT +01:00) Copenhagen .... the corresponding text
is,

Daylight Saving Time
Start Date/Time: Last Sunday of March at 02:00:00
End Date/TIme: Last Sunday of October at 03:00:00

Very simple rule, easy for a computer to understand :-)

Ivar B. Jessen

//-----
function getFileCreatedGMT(cF
ilename)

fso = new oleautoclient("Scripting.FileSystemObject")
d = fso.GetDrive(fso. GetDriveName(cFilena
me))
cFileSystem = d.fileSystem

f = fso.getFile(cFilename)
dateCR = ctodt(f.DateCreated())

init()

deltaTime = (localTime() - systemTime())*24

if cFileSystem = "NTFS"
? "DateCreatedGMT = ", dateCR - deltaTime/24
elseif cFileSystem = "FAT32"
? "DateCreatedGMT = ", dateCR - (dateCR.getTimeZoneOffset()/(60*24))
else
msgbox("You have a problem!")
endif

function systemTime
*******************
st = new SYSTIM()
GetSystemTime(st.value)
sysVal = getvalues(st)

return ctodt(substr(SysVal,
1, len(sysVal) - 4))

function localTime
******************
st = new SYSTIM()
GetLocalTime(st.value)
locVal = getvalues(st)

return ctodt(substr(locval,
1, len(locVal) - 4))

function init
*************
set proc to :samples:structure.prg additive
#include winbase.h
#include structAPI.h

extern CVOID GetSystemTime( CPTR ) kernel32
extern CVOID GetLocalTime( CPTR ) kernel32

return

function getValues(st)
********************
**
dd = int(st.getmember('wDay')) + "-";
+ addZero(st. getmember('wMonth'))
+ "-" ;
+ addZero(st.getmember('wYear')) + " " ;
+ addZero(st.getmember('wHour')) + ":" ;
+ addZero(st. getmember('wMinute')
) + ":" ;
+ addZero(st. getmember('wSecond')
) + ":" ;
+ addZero1(st. getmember('wMillisec
onds'))
return dd

function addZero(nVal)
********************
**
return iif(nVal < 10, "0" + int(nVal), int(nVal))

function addZero1(nVal)
********************
***
if nVal < 100 and nVal >= 10
retVal = "0" + int(nVal)
elseif nVal < 10
retval = "00" + int(nVal)
else
retval = int(nval)
endif

return retVal

class SYSTIM of structure
super::addMember( TYPE_WORD, 'wYear')
super::addMember( TYPE_WORD, 'wMonth')
super::addMember( TYPE_WORD, 'wDayOfWeek')
super::addMember( TYPE_WORD, 'wDay')
super::addMember( TYPE_WORD, 'wHour')
super::addMember( TYPE_WORD, 'wMinute')
super::addMember( TYPE_WORD, 'wSecond')
super::addMember( TYPE_WORD, 'wMilliseconds')
endclass
//-----

Rick Miller

2005-11-22, 8:23 pm

Sorry for the delay, been away for a few days.

Bruce Beacham <bbeacham@beacham.no-spam.co.uk> wrote in
news:bqUD6dO7FHA.1520@news-server:

> What I've learned from this is that this command:
> protect bokay, date, fileTime, hour, message, minute,;
> month, runtime, second, sysTime, year
> - protects class properties that are so-named - despite the
> absence of a WITH block or a "this." prefix. That wasn't so
> obvious late last night!
>
>

> Yes. I was accessing it from another method (getfilestamp()) -
> but that too is protected. I'm surprised I could run it.
----

Yes, would think that inaccessible message would
have come with the call rather than when attempting
to access the property (fileTime).

> So I tried this:
> set proc to :duflp:filestamp.cc
> fs = new filestamp()
> fs.filename = _dbwinhome + "bin\plus.ini"
> ? "File " + fs.filename + " exists: ", file(fs.filename)
> ? fs.get("filestamp")
> ? fs.get("time") // return time
> ? fs.get("date") // return date
>
> That gave me the current date and time, not the date and time of
> the file.
----

As Ivar mentioned, the plus.ini changes at each start of dBASE).
You might try using a different file.

The date and time returned from
? fs.get("date")
? fs.get("time")
should be the Local (date, time) values.

> Ultimately I'm trying to reach the time of a file suppressing the
> effects of Daylight Saving, so always comparing files using
> "winter time", or even a "winter time" that also ignores time
> zones.
----

The API functions for UTC are available,
so maybe a new method for the UTC date/time
would be helpful. It may be a better answer
than trying to Localize for GMT with/without
daylight savings time on this task.

Did this a few years ago, so maybe a little
facelift for it is in order :-)

Rick Miller

Rick Miller

2005-11-22, 8:23 pm

Placed a subclassed object in the shared-code newsgroup.

filstampUTC.cc

It works the same way as filestamp except it uses UTC
date and time with files.

Rick Miller

Bruce Beacham

2005-11-24, 9:23 am

Rick Miller wrote:
> Placed a subclassed object in the shared-code newsgroup.
>
> filstampUTC.cc
>
> It works the same way as filestamp except it uses UTC
> date and time with files.
>
> Rick Miller
Thanks, Rick. I'll take a look next weekend (this one's a family
weekend in London).

Bruce

Sponsored Links