When I use the Dir() function in OI9.3/Arev32 to obtain the Date/time from a pdf file, it is 8 hours ahead. Is it not adjusting for the GMT?

Or rather - it seems inappropriately - to be setting the vaue back to GMT. So my 8pm file is displayed 8am (local is 12hrs ahead GMT)

I have found also that the datetime of a file created on a workstation can differ if that file is copied to the network server, by the GMT difference in hours. I had to wrap dir() with my own routine that checked to see if the file was local and adjust, or not, the hours from GMT.

Perhaps a Windows expert can chime in here.

Dave Harmacek

Harmacek Database Systems

I believe this issue with the DIR function has been around for many years. It is the NTFS filing system that stores the data as GMT. It is the Windows operating system that is setting the time to GMT. The FAT filing system does not.

I got around it by determining the "System" time (GETSYSTEMTIME) and the "Local" time (GETLOCALTIME). You now have the values to use to adjust from GMT time to local time.

OK,

So the NTFS filing system stores the data as GMT - and displays it as local time. This being the case, would be nice to see this doced - the possible need for a localisation wrapper - in the associated OI help file.

Richard

This issue with the dir() function recently came up and here is a possible solution. Pass into this program the internal date and time you get back from the dir() function. I tested it on several files and the only problem I have found is that it only uses today's rules for DST. For example I checked a file with a date stamp of 03/15/2005 and it treated it as if we already turned the clocks ahead, which would be true now but in 2005 we wouldn't have done so until the first Sunday in Aril.

Subroutine UTC_TO_LOCAL(fileDate, fileTime)

common /UTC_TO_LOCAL/init%,jscript%

If Assigned(init%) Else init% = ''

If init% else

jscript% = OleCreateInstance("MSScriptControl.ScriptControl")

jscript%->Language = 'JavaScript'

init% = 1

script = 'function UTCtoLocal(year,month,day,hours,mins,secs)'

script := '{'

script := '   var mydate = new Date();'

script := '   mydate.setUTCFullYear(year:,month,day);'

script := '   mydate.setUTCHours(hours,mins,secs, 0);'

script := '   ans = mydate.toLocaleTimeString();'

script := '   return ans'

script := '}'

x = jscript%->AddCode( script )	

End

basetime = fileDate + fileTime/86400

obasetime = Oconv(basetime, 'DT/^S')

odate = Field(obasetime, ' ', 1)

otime = Field(obasetime, ' ', 2)

year = Field(odate, '/', 3)

month = Field(odate, '/', 1)

month -= 1 ;* This makes the date come out correctly

day = Field(odate, '/', 2)

hours = Field(otime, ':', 1)

mins = Field(otime, ':', 2)

secs = Field(otime, ':', 3)

ans = jscript%→Run('UTCtoLocal',year,month,day,hours,mins,secs)

Return ans

Just to add a bit more in here:

The dir() function uses a combination of two Windows API calls:[list]GetFileAttributesEx

FileTimeToSystemTime

[/list]

This means that the returned time is always in Coordinated Universal Time (UTC), which just happens to be the same as GMT (center of the universe and all that :wink: ). File times are documented here.

You can find out the local time zone information using the GetTimeZoneInformation Windows API function which will also tell you if you are in Daylight Savings Time. If you've got the Sprezzatura Windows API package installed this function is already prototyped along with the structures it uses. There is also an insert record "winAPI_SystemTime_Equates" that has all the necessary declarations.

Carl Pates

Sprezzatura

The Sprezzatura Blog

World leaders in all things RevSoft

Geezes, forgot all about your API Package. thx

Thanks for that Captain Kopter, but shouldn't the OI tools return the information without further expansion by the developer? Understanding the underlying api's etc … We have compilers so we don't have to write machine code (oh that was fun). The language and its functions should have that built into it. Yes?

View this thread on the Works forum...