Afternoon times as next day

[gfineman]

I have tens of thousands of small HTM files that have a date and time as part of the Title. I set my system clock to that date and time and then created the file. Thus Explorer shows that each file has both its creation date and modified date at that past date and time. This is done so that Zoom can sort the search results by date. I index off-line using the cgi version for Linux.

When I run a search all of the documents with an AM time show the correct date and time in gray on the lower line. However, the ones with a PM time show the date as the next day (the time is correct). The sorting work fine (it is just the display), so it is not very important in my application but I hate to have things happen that I do not understand. Is anyone else seeing this result?

Gabe Fineman
Washington DC

[Anonymous]

You might has found it easier to download a utility program that can modify file dates and times as a batch job. There is a command in Unix called "touch" that does this. I am sure there must be similar tools available for Windows.

Also in V4.1 of Zoom (coming soon), you can specify the date and time of the file in HTML meta-data. So you might not need to worry about the file creation time if you can include meta data in the files.

The difference in dates that you have seen might be due to time zone differences. You could check the zoom_datetime.zdat file to determine the date and time that the indexer recorded.

------
David

[gfineman]

Thanks for you prompt response and help.

You might has found it easier to download a utility program that can modify file dates and times as a batch job.There is a command in Unix called "touch"

Touching files is possible, but not as simple, in the Win-tel world. However, I was unable to find any batch file that in either world that set a file's date based on information embedded within the file.

The difference in dates that you have seen might be due to time zone differences. You could check the zoom_datetime.zdat file

Looking at the files themselves using Windows Explorer to show the creation/last modified dates. the date and time correspond exactly to embedded date and time. Looking at the zoom_datetime.zdat file I see offsets of four and five hours in some cases and no offsets in others. However, I am unable to understand why this should happen when I am indexing on my local machine. Looking at sort results on the web site, the sort seems to work fine. That is, files are sorted properly even if the the date is displayed incorrectly. The common thing that I see on the web site is that the date in gray is increased by one if the time is after 13:00 hours.

So, my questions are how does Zoom calculate this date? Does it use the modified date? Does it convert the modified date into GMT?

-Gabe Fineman
Washington, DC

[Ray]

Zoom uses the Last Modified date and time. It does not do any additional conversions besides what the file system or OS may be doing. Can you tell us what version of Windows you are using? And what file system are the files located on? (FAT? NTFS?)

You said that sorting works "correctly" despite it showing the incorrect date time. Can you give us an example of what you mean? Does it for example, mean that two results may actually be shown with a date time which conflict with the sort order? Or is it simply that the incorrect date time happens to still be in the same order (for example, if all files are +1 hour, then the sort order would naturally not change).

Perhaps it would be best if you can give us a URL to your search page, and provide some examples of what you mean. Alternatively, you can zip up your search files (all ZDAT files, etc.) and e-mail them to us with an example scenario to replicate.

[gfineman]

Some replies were lost in a recent Forum failure, so I am reposting this to try and complete the thread for people who will read it in the future.

I have received no messages from other users seeing the same problem, so I have to assume that it is unique with my system. Probably some corruption of the time zone registry keys. Ray looked at the issues extensively and did find some allied problems in the cgi program that are fixed in build 4.1.1002, so some good may have come from this.

I have switched from fudging the creation and last modified dates on my files to using the new (4.1) meta-tag for Last-Modified. It has avoided the problem.

For those using this new Last-Modified meta tag, please note that it is fussy about the format of the date. It expects fixed length fields so that Monday July 4, 2005 will not work. It expects Mon, 04 Jul 2005 with the day of the month as always two characters and it needs 24 hour time. I work in visual basic (for applications) and the code I use is much more forgiving about the input format. The date, time string I get from Yahoo is in the form Mon Jul 4, 2005 3:13 pm and I use the Format statement
'Time for meta-tag Must be in format of Sat, 07 Apr 2001 21:58:08 GMT-5
dTag = Format(DATEdate, "ddd, dd mmm yyyy") 'DATEdate is in form Sat Apr 7, 2001
tTag = Format(DATEtim, "hh:nn:00") & " GMT-5" 'DATEtim is in form 9:58 pm
DateTag = dTag & " " & tTag 'Date/Time for Meta-Tag

I hope that this helps some other users

Gabe Fineman
Washington DC (Still denied political representation)