Creator Classic Verify Error - Time Stamp

[djay-z]

When I create a CD, all the file stamps on the CD are one hour ahead of the source files on my hard drive. When I have verify turned on, ALL the files have verify errors due to the time stamp not matching.

 

I had not burned a CD for some time (before daylight savings time change?) so this could be related.

 

Any ideas on how to fix this?

[james_hardin]

Check the time zone setting for your PC.

 

There is a choice in Classic but none to add an hour.

[mauchzv]

I'm having this exact same problem. We're running Roxio CD Creator 6.

 

This is an isolated domain on which we recently ran the Windows DST update on all systems. The time being shown in the system tray and on file time stamps are correct. When I made a CD using creator classic, the time stamp on the files in windows explorer are 1 hour long. When I import the CD into Creator Classic to add more to the disc, the time stamps are once again correct.

 

I burned files to disc using both Drag-to-Disc and the Windows Explorer burning method. Both showed the correct time stamp in windows explorer. Here is the disk data for all the burned discs.

 

Disc 1 - Burned using Creator Classic

File System: UDF

Disc Information option in Creator Classic: Shows "Data Mode 1 or Audio CD"

 

Disc 2 - Burned using Drag-to-Disc

File System: Drag-to-Disc (shows UDF on system without Roxio Installed)

Disc Information option in Creator Classic: can't open, just shows "Being used by Drag-to-Disc"

 

Disc 3 - Burned using Windows Explorer

File System: CDFS

Disc Information option in Creator Classic: Shows "Data Mode (2xa)"

 

Obviously, this seems to be a problem with Creator Classic. For some reason it isn't taking DST into account when writing the files. I don't know if this will change when we reach the old DST date or not. It seems weird to me that Roxio would use it's own time adjustments when writing instead of the system's time adjustment.

[Jim_Hardin]

How is it a problem with only 2 of you in a 3 year period???

 

You are 5 versions out of date and the OP is 3 versions behind… Millions of people use this software without this problem. The only ones who see it eventually track it down to one of their servers.

 

 

[mauchzv]

How is it a problem with only 2 of you in a 3 year period???

 

You are 5 versions out of date and the OP is 3 versions behind… Millions of people use this software without this problem. The only ones who see it eventually track it down to one of their servers.

 

first of all, thank you very much for your help. I appreciate and information you can provide.

 

I'm not sure how it could be a problem with the server when we're not seeing it anywhere else, but I'm definitly open to pursue all options. I don't want to label it as Roxio's Problem. We haven't updated in the past because we haven't had a need to. When it works it works. Roxio can take that as a bode of confidence.

 

My guess is this. We're using a really old version of Roxio and the DST changes are very new. For some reason, the changes in DST aren't being interpreted when the disc is read after burning by explorer. (if correct, this would cease to be a problem when the old date hits, but only for discs written then or after). Do you know how Roxio 6 is calculating the time written to the CD? It almost seems like it's doing it's own DST adjustments. One more thing I don't know is if the time stamp on a CD file is the zulu time or the adjusted Timezone/DST time?

[mauchzv]

OK, some new information and a new theory. Here's a situation based on my testing results. I tested this on a computer we hadn't put the DST update on yet.

 

Let's say I create a file at 9:00am. I then burn this to a disk using Creator Classic. On a Computer with the DST update, Windows Explorer will show a time of 10:00am on the file burned to the disk. If I do this same procedure on a computer without the DST update, the time shown on the system is 8:00am because it thinks DST hasn't ended yet. When I burn it using creator classic it still shows 8:00am as creation time.

 

Here's my theory. The time written to the disc is zulu time (or GMT or whatever) which for me in central TZ means 9:00am + 5 hours = 2:00pm. When Roxio writes a disc, it adjusts to GMT from the Time zone relative time it got from the computer Instead of simply getting the GMT stored in the system to begin with. Therefore, since it thinks DST hasn't started yet, it adds 6 hours instead of 5 hours (9:00am + 6 hours = 3:00pm). When Windows reads the disc and adjusts the time it sees in Explorer for me to see the time stamp of the file, it only subtracts 6 since it thinks DST has started (3:00pm - 5 hours = 10am). Thus the problem.

 

However, in a computer where the DST update hasn't been installed yet, we don't get this problem because both the computers are still jiving with each other (8:00am + 6 hours = 2:00pm - 6 hours = 8:00am). However, both are incorrect because DST has started and it should be viewing the time as 9:00am.

 

Hopefully that all made sense. I'm guessing that this hasn't been reported that much because not many people still use this old software and it's easy to miss. Also, if I'm right it's only happening in the window between the old and new implementations of DST.

[mauchzv]

So I'm guessing I'm not going to be getting a reply here. If I could just get some type of verification that upgrading would fix the problem then we'd probably do it. As it stands now, we've got no reason to believe that it will. Rather, we've just got a response that might have been making fun of me and then said the fault was in our own server. Personally, I don't see how it could be possible considering that roxio is a desktop application and isn't being served anything.

 

Also, if you if this problem had been solved in other ways I would at least hope that I could hear the ways in which it was solved. Right now, I got nothing. We are a prospective cusomer here you know.