> My coworker who is putting together the tutorial on UDF and ISO CD-ROM
> dating has run into a couple more problems and I was hoping those on the
> list more familiar with these specifications could assist him.
>
> Regarding UDF, he's working with the date and time stamp C4 0F D2 07 0A
> 01 0A 2E 0C. He's been able to compute and test all values against test
> burns except the 16-bit time zone and type value of 0xC4 0x0F. How does
> this translate into time zone and type?
The following code can be used to decode timezones as specified by the UDF
specification.
UINT16 UtcOffset; /* 12-bit signed number in twos complement */
UtcOffset = (TypeAndTimezone & 0x7FF);
if ((TypeAndTimezone & 0x800) == 0x800)
{
UtcOffset = -1 * (0x800 - UtcOffset);
}
The timestamp you described, 0x0FC4 because of big endian recording, is in
fact:
TYPE 0
TIMZEONE: FC4 [12 bit signed number] = -60
This is not a legal timestamp for UDF because of the following quote from
the specification (below). However, I think the person writing this volume
tried to indicate that the stamp has an offstet of -1 hour (1 hour east of)
the UTC zone.
<quote>
2.1.4.1 Uint16 TypeAndTimezone;
For the following descriptions Type refers to the most significant 4 bits of
this field, and TimeZone refers to the least significant 12 bits of this
field, which is interpreted as a signed 12-bit number in two's complement
form.
(ON READ) The time within the structure shall be interpreted as Local
Time since Type shall be equal to ONE for OSTA UDF compliant
media. ^^^^^^^^^^^^^^^^^^^^^^^^^^
(ON WRITE) Type shall be set to ONE to indicate Local Time.
^^^^^^^^^^^^^^^^^^^^^^^^
</quote>
Kind regards,
Pieter-Bas
-----------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management
and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Thu Dec 19 2002 - 19:29:17 PST