Time stamp is wrongly displayed

The timestamps of ".tib" archive files are displayed incorrectly in terms of a wrong time zone when it is displayed on Windows Explorer in the following situation. I am using TI 9.0.2323. I am using Windows XP.

Boot the PC from the bootable CD of TI. Let the non-MSDOS version of TI on the bootable CD launch. Back up files to a CD-RW. (I backed up at 6:00 am EST, New York time.)

Restart the PC from the internal hard drive. Using the Windows Explorer, open the CD-RW and look at the timestamp of the ".tib" archive file on the CD-RW. Windows Explorer displays the timestamp wrongly. (Windows Explorer displays "1:00 am", though I backed up at 6:00 am. Note that 1:00 am is the Hawaiian time for 6:00 am ET. According to the "Date and Time" control panel on this PC, the time zone is set to New York time.)

On the other hand, the Restore Data Wizard of TI displays the backup time correctly.

By the way, just for curiosity, I tried to open the CD-RW on a Macintosh. Mac OS 9 displayed the timestamp of the ".tib" archive file on the CD-RW correctly.

The following Microsoft article mentions the discrepancy of timestamp among FAT, NTFS and ISO-9660.
http://msdn.microsoft.com/library/en-us/sysinfo/base/file_times.asp?frame=true

 

Hello hi-there,

I raised a similar observation some months ago. You will find Acronis Support's answer in this earlier thread of mine titled <Bug in True Image Rescue Mode>.

Regards

 

The GMT reason mentioned in the above link is not the whole story as is shown by the following:

I used the TI 9 build 2323 bootable CD to create a file/folder .tib in a Windows NTFS partition. The .tib was then restored to a new location in the same partition a few minutes later. Note that I have rounded the times below by a minute or so just to avoid confusion and make comparison easier. This minor time difference is due to the time it took to actually do the backup and restore operations.

The .tib was created at my local date/time of 04Jan2006 09:30

BIOS and Windows systray showed time of 09:30.
My Windows 2000 system Date/Time Properties shows:
timezone: AUS Eastern daylight Time
GMT+10 (this is Sydney Australia)
Automatically adjust clock for daylight saving changes

WorldTimeServer website showed:
Sydney UK
09:30am 10:30pm (note this is the previous day 03Jan2006)
Standard Time +0000 UTC

I restored the .tib to a new location on the same partition.
The Restore data wizard correctly showed .tib creation at 04Jan2006 09:30.
Check archive option also showed this time.

However, using Windows 2000 explorer to view both the .tib file and the restored folder/files I found:

The created .tib has creation date/time of 04Jan2006 8:30PM
The restored folder has creation date/time of 03Jan2006 10:30AM

Stephen hawkins would be interested if it were really true that the restoration occurred 34 hours BEFORE the .tib was created!
It surely would be an interesting universe.

I suspect the true explanation is that TI 9 build 2323 has several distinct problems when handling local time and GMT.

The .tib creation time is 11 hours after it really was created - if this 8:30PM time is meant to GMT then it is very wrong since the correct GMT time would be 10:30PM on 03Jan06 (note that is the previous day in relation to my local date). I'd guess that it incorrectly makes the daylight saving adjustment and also forgets about it being the previous day.
Whatever this 8:30PM time is meant to be, the Restore data wizard at least converts it back to the correct time to display it.

The restored folder has creation time which is 23 hours before it really was created - if this date/time is meant to be GMT then the conversion to GMT is almost correct however it keeps the local time 'AM' instead of the correct GMT 'PM'.

Regardless of what appears to be several bugs in time conversion to GMT I would suggest that the practice of trying to create NTFS files or folders with GMT times is flawed. Acronis does not need to correct the bugs in GMT time conversions I have mentioned above but it needs to redesign the whole date/time logic so that all folders/files use the local time instead. This should ensure that all files in a partition have a date/time consistent with 'the arrow of time' and keep Stephen Hawkins happy.

 

It seems that the rescue version of TI 9.0.2323 violates the ISO-9660 specification for CD and the UDF specification for DVD, when TI stamps times on these media for files.

ISO-9660 and UDF are identical, as long as the timestamp format is concerned. You can look at the requirements for the timestamp format in the following document published by Optical Storage Technology Association.
http://www.osta.org/specs/pdf/udf150.pdf

This specification requires the timestamp to be equipped with the time zone field as well as the fields for hour, minute and second. If the DVD/CD writing program does not know the time zone in which the PC is located, then the specification requires the time zone field to be set to the code -2047, which means, "The time zone is unknown."

It seems that Windows stores the PC's time zone in the Windows registry on the internal hard drive. However, when TI is running in the rescue mode from the bootable CD, it is difficult for TI to access the time zone information stored in the Windows registry on the internal hard drive. Hence, TI in rescue mode does not know the time zone in which the PC is located. In this case, by the UDF specification, TI is supposed to set the time zone field to -2047, "time zone unknown." However, I suspect that your engineer mistakenly programed TI to set the time zone field to 0, which means "London."

Whether the time zone field is set to "Unknown" (-2047) or "London" (0) must make a big difference. Please pay attention to the fact that Windows Explorer displays timestamps correctly after TI wrote backups to FAT drives such as floppy diskettes. Files on FAT drives are not associated with any time zone information. This lack of time zone information on FAT drives must have the same effect as the time zone field set to "Unknown" on CD's.

On the other hand, after TI in rescue mode burnt backups to CD's on a PC located in New York, Windows Explorer displays the timestamps in Hawaiian time. Why in the heck do I have to live with Hawaiian time, though I live in New York? If the timestamps were displayed in GMT, I would be able to handle it because I am accustomed to convert between New York time and GMT. However, I am not accustomed to Hawaiian time at all. TI certainly screwed up timestamps.

Why is Hawaiian time displayed, even though it is relevant to neither the location of the PC nor the coordinated universal time? A hint is given by the fact that GMT is 5 hours ahead of New York standard time, while Hawaii is 5 hours behind New York. GMT and Hawaiian time have the same offset from New York time, except that they in the opposite direction.

For example, TI in rescue mode wrote a backup to a CD in New York at 6:00 in New York time, which was 11:00 GMT. I suspect that TI put "6:00" into the time field and put "London" to the time zone field on the CD. Later, after re-booted to Windows on the internal hard drive, Windows Explorer found the timestamp "6:00" being marked "London" time zone on a PC located in New York. Hence, Explorer subtracted 5 hours from 6:00, believing that it was converting GMT into New York time. However, in actual fact, it converted New York time into Hawaiian time. If "6:00" had been marked "Unknown" time zone, then Windows Explorer would not have attempted the useless subtraction and would have displayed "6:00" straight.

Please alert your engineers at Acronis to make sure the rescue version of TI follows the ISO-9660 and UDF specification concerning timestamps. The specification requires the time zone field to be set to "Unknown" instead of "London" if the time zone is unknown.

 

In summary:
When creating files on CD or DVD then the ISO-9660 and UDF specifications should be followed.
When creating files on an NTFS partition the PC local time, timezone and daylight savings adjustment need to be used following whatever is the Microsoft standard. This may be complicated by access to the registry however it needs to be done.

 

In Post #4 of this thread, I pointed out a likely bug of TI 9. Did you (Acronis Tech Support) pass the information to your engineers? What did they say? Did they admit the bug?

 

I submitted a bug report to Acronis Support and included a link to this thread. I requested that Acronis investigate this issue and fix the problems.
I asked that I be advised of actions taken.
On 6 Jan 2006 I received a reply stating that my report was received and was being processed.
The reference given was "[Acronis #452226] File/Folder creation date and time".
I am awaiting further feedback from Acronis.

 

Thanks, tachyon42.

hi-there

 

Received email from Acronis today:
"This issue has been forwarded to our Development Team. We will let you know the results of their investigation as soon as possible. As this can take a few days, we apologize in advance for any delay with response."

 

Thanks again, tachyon42.

hi-there

 

In this thread, I have been talking about the problem of timestamps of ".tib" files mainly on CD's (and theoretically on DVD's) so far. In this post, I am going to address the timestamp issue concerning NTFS-formatted hard drives.

It seems that Microsoft does not expect any OS that lacks time zone information to dare to write timestamps to NTFS-formatted disks. Recall that, whenever you install Windows XP to your PC, the installer asks you to input your time zone, so that your copy of Windows XP will know your time zone. I think that this time zone information is stored in the Windows registry.

The BIOS clock of any PC running any major Microsoft OS is supposed to stay on local time, no matter whether it is Windows XP, 2000, 95, NT, 3.1 or MS-DOS. However, by Microsoft's specification, the internal format of timestamp for files on NTFS uses UTC. Therefore, whenever a file time is stamped on a NTFS-formatted disk, the time zone offset has to be subtracted from the BIOS clock. (In the Western hemisphere, the offset is negative. The subtraction of a negative number is equal to the addition of the absolute value of the negative number. By the way, while the internal format of timestamp stored in a NTFS disk uses UTC, Windows Explorer displays timestamp in local time after Explorer converts it back from UTC to local.)

This required conversion from BIOS's local time to NTFS's UTC would be impossible if the time zone information is absent. Therefore, if neither the OS nor the file writing program knows the time zone offset, then such an environment is not qualified to write to NTFS-formatted disks.

As I wrote in Post #4 in this thread, the rescue environment from TI's Bootable CD does not know the time zone in which the PC is located. Hence, TI's rescue environment cannot fulfill the conversion required by Microsoft. Therefore, the rescue environment of the present version of TI is NOT even qualified to write to NTFS-formatted disks!

Therefore, Acronis should correct TI so that the rescue environment will get the time zone information. How? From a programmer's viewpoint, the easiest implementation is to ask the user. In the "Options" dialog that derives from the "Tools" menu of the rescue version of TI, add a new field for time zone. A pop-up list of time zones would be nice.

However, it would be bothersome to the user if he/she has to set the time zone every time he/she backs up in rescue mode. Therefore, let the "Bootable Rescue Media Builder" ask the user for the time zone, when the Builder creates the bootable CD. Then, let that time zone be the default time zone for the time zone field in the "Options" dialog in the rescue environment. This scheme would be sufficient for most users, except for those who travel across time zones every day.

In fact, it is very easy for the "Bootable Rescue Media Builder" to obtain the time zone information from the active Windows registry or wherever the active copy of Windows XP stores the time zone information. A C++ programmer can use the GetTimeZoneInformation() function to have his Windows program obtain the time zone information from the active copy of Windows XP. However, this function cannot obtain the information from an inactive copy of Windows XP -- a copy of Windows XP that is not running.

Linux programs cannot even access this GetTimeZoneInformation() function of Windows. It is very difficult for Linux programs to obtain information from Windows registry. (It may be still possible, though.) The full rescue environment from the bootable CD of TI 9.0 uses Linux instead of Windows. So, it is very difficult for TI in the rescue environment to obtain the time zone information from any copy of Windows.

When the "Bootable Rescue Media Builder" asks the user for the time zone as I am proposing, let the "Builder" fetch the time zone from Windows and let the "Builder" highlight that time zone for the user. If the user accepts that time zone, then the rescue CD will be burnt with that time zone as the default time zone for the rescue environment.

Before I finish writing this post, let me point out one more thing. As I wrote above, the BIOS clock of any PC running any major Microsoft OS is supposed to stay on local time. However, it seems that many Linux users prefer to set the BIOS clock to UTC. However, if the PC has both Windows and Linux installed for dual boot, then the BIOS clock of the PC should be set to local time.

The programer who wrote the full rescue version of TI must be a Linux guy, because it is a Linux program. He may have boldly assumed the BIOS clock of every PC to be on UTC. However, the main version of TI is a Windows program. I guess that most PC's that TI backs up run either solely Windows or at least dually Windows and Linux. Therefore, most PC's that TI backs up are supposed to have their BIOS clocks set to local time. The present bug of wrong timestamps may have arisen from the Linux programer's misassumption about BIOS clocks.

Let me summarize this post. Most PC's that TI backs up have their BIOS clocks set to local time. To write to a NTFS drive attached to a PC whose BIOS clock is set to local time, the writing environment has to have the time zone information on hand. To equip TI's rescue environment with time zone information, I propose the following scheme. Acronis should add a time zone field to the "Options" dialog that derives from the "Tools" menu of the rescue version of TI. To ease the user, let "Bootable Rescue Media Builder" fetch the time zone from Windows. If the user agrees on the time zone highlighted by the Builder, then the Builder will burn the rescue CD with that time zone as the default value for the time zone field of the rescue environment. I hope this post will help Acronis solve the timestamp problems.

Links:

The internal format of timestamp for files on NTFS
http://msdn.microsoft.com/library/en-us/sysinfo/base/file_times.asp?frame=true

Why does Windows keep your BIOS clock on local time?
http://blogs.msdn.com/oldnewthing/archive/2004/09/02/224672.aspx

GetTimeZoneInformation() function
http://msdn.microsoft.com/library/en-us/sysinfo/base/gettimezoneinformation.asp?frame=true

 

A further complication is that knowledge of daylight saving would also have to be built into the Rescue CD. Since the effective date for daylight saving can change at the whim of a politician I wonder how Windows manages this issue when deciding whether to make the daylight savings adjustment?

The alternative approach of accessing the time zone from an NTFS partition (with any problems which might be due to the Linux nature of the Rescue CD) can only work if that partition has a Windows system installed. It couldn't work for an NTFS partition which is just used for data and doesn't have an installed OS.

Not exactly an easy issue to solve.

 

Thanks for your feedback, tachyon42.

The GetTimeZoneInformation() function I mentioned in my Post #11 obtains the information on when daylight saving time starts and when it ends. To learn what information the GetTimeZoneInformation() function obtains, look at the following Microsoft document.
http://msdn.microsoft.com/library/en-us/sysinfo/base/time_zone_information_str.asp?frame=true
In the above document, read the description of the fields listed below "Members", e.g., Bias, StandardName, StandardDate, etc.

What do you mean by "The alternative approach"? Are you talking about your own approach alternative to my approach?

According to my approach, the rescue environment will not peep into Windows to obtain the time zone. Instead, the "Bootable Rescue Media Builder" obtains the time zone information from Windows. The Builder then burns the time zone information into the rescue CD. To run the Builder of TI 9.0, Windows 98 or above must be running. So, a Windows is always available to the Builder whenever the Builder runs.

In fact, the time zone information that the GetTimeZoneInformation() function obtains from Windows contains not only the offset but also the daylight saving schedule. Let the Builder burn this extended information on time zone into the rescue CD. Then, the rescue CD will be able to automatically adjust the offset whenever the transition between DT and ST occurs. Except for special circumstances, the rescue environment will always have the correct offset with DT and ST taken into account. I live in New York. If it is winter, the rescue environment will automatically set the offset to "-5:00". If it is summer, it will automatically set to "-4:00".

In case that the burnt time zone information does not work, the rescue environment should provide an option to override the burnt information. For example, if I go to Los Angeles in winter for just one day, I would type in "-8:00" in the rescue environment. However, the rescue environment is on CD. The time zone offset that the user types in during rescue mode cannot be saved. So, if I stay in Los Angeles for one month, then I would burn a new rescue CD with the time zone information of Los Angeles.

Similarly, in case that the extended information on time zone that Windows passes to the Builder does not work, the Builder should provide an user-interface in which the user can manually configure the time zone information. A sudden change of the effective date for daylight saving at the whim of a politician can be the case.

 

I meant the approach whereby the Rescue CD accesses the time zone information from the NTFS partition on which it is trying to create a folder/file.