Re : OT, zal nog niet voor direct zijn die UTC codering

Bericht van: Peter (Mariakerke bij Gent) , 29-10-2008 02:34 

Uit de pdf van de nieuwe werkgroep voor metadata (Adobe, Apple, Canon, Microsoft, Nokia en Sony). Meer via de link ondering.

"Time-zone handling
The handling of date/time values, and especially time zones, is conceptually easy but requires some
care to avoid confusing users. The potential problems are typified by the differing representations of
date/time values in Exif and XMP. (For our purposes here the Exif sub-seconds portions are ignored,
but they are of course incorporated in software conversions.)
Exif date/time values such as DateTimeOriginal do not contain time zone information. The camera is
presumably in an appropriate local time when a photograph is taken, but there is no indication in the
Exif metadata of what that time zone was. The photograph's time zone MUST NOT be presumed to be
the same as that of a computer later used to process the photograph.
The XMP specification formats date/time values according to the W3C note
“http://www.w3.org/TR/NOTE-datetime”. In this note a time zone designator is required if any time
information is present. A date- only value is allowed. The XMP specification has been recently revised
to make the time zone designator be optional.
The representation of time zone as an offset from UTC can be ambiguous with regard to daylight
savings time (DST). While date information can provide a strong hint, the use of DST is not universal
and the date checking is complicated by changing rules for the start and end of DST in various
locations. These issues are beyond the scope of this document; they may be addressed in a future
revision.
The following general behaviors are recommended for time zone handling:
 A Consumer MUST NOT arbitrarily add a time zone. E.g. when importing Exif
DateTimeOriginal to XMP (xmp:CreateDate), use a zone-less form for the
corresponding XMP value.
 A Changer MUST NOT implicitly add a time zone when editing values. It is okay to be
explicit about time zones if desired. Consider the typical case of correcting
DateTimeOriginal values for an incorrectly set camera time. This must not be implicitly
done as though the new time were in the computer's time zone.
 If the Exif contains the GPSDateStamp and GPSTimeStamp tags, software MAY use
that information to infer a time zone. This should be done with care, e.g. verifying that
the DateTimeOriginal plus inferred offset is within a few seconds of the GPS date and
time..
 When time zone information is available, XMP values SHOULD be stored using the
local+offset form, not the “Zulu” form (for example, use “2008-04-30T12:34:56-06:00”
instead of “2008-04-30T18:34:56Z”). The local+offset form carries additional
information, the Zulu value is easily determined when needed, e.g. for sorting in a UI.
 A user interface MAY display time zone information if available; however, related
functionality MUST NOT convert a time to the computer's local time for display.
 According to the Exif specification, missing information SHOULD be filled up with
spaces in the Exif values."

http://www.metadataworkinggroup.org/pdf/mwg_guidance.pdf
Bericht laatst bijgewerkt: 29-10-2008 02:35

Enkele 'mist' foto's *PICS*   ( 392)
Saskia (Wageningen) ( 11m) -- 29-10-2008 00:52
Nou, op z'n minst dan toch stemmingsvolle   ( 152)
Hans (Eindhoven) ( 17m) -- 29-10-2008 00:58
Zeker mooie sfeerfoto's!   ( 62)
Tim (Steenwijkerwold) ( 9m) -- 29-10-2008 08:47
Re : Nou, op z'n minst dan toch stemmingsvolle   ( 114)
Tinus (Rozenburg) -- 29-10-2008 01:11
Re : Aargh! Goed dat je 't zegt. ben da ook vergeten   ( 150)
Peter (Mariakerke bij Gent) ( 7m) -- 29-10-2008 01:10
Re : Aargh! Goed dat je 't zegt. ben da ook vergeten   ( 76)
Saskia (Wageningen) ( 11m) -- 29-10-2008 09:04
Re : OT, zal nog niet voor direct zijn die UTC codering   ( 93)
Peter (Mariakerke bij Gent) ( 7m) -- 29-10-2008 02:34