Fwd: sample UDDF file

[Miika Turkia]

On Wed, Feb 27, 2013 at 6:32 PM, Dirk Hohndel <dirk at hohndel.org> wrote:
> Linus Torvalds <torvalds at linux-foundation.org> writes:
>
>> On Wed, Feb 27, 2013 at 8:00 AM, Miika Turkia <miika.turkia at gmail.com> wrote:
>>>
>>> This time format is not currently parsed in XSLT. I thought that it
>>> was already implemented in Subsurface, but it seems that the time is
>>> ignored by Subsurface parser if the datetime is given as is to it.
>>
>> The UDDF crazy time format *is* parsed by parse-xml.c, but it's only
>> parsed for the UDDF datetime field.
>>
>> And if your XSLT transformation removes the UDDF marker, then we won't
>> do any of the UDDF special parsing.
>>
>> So the XSLT needs to either fix the date format, or it needs to leave
>> in the UDDF marker (which is just the "<uddf version=xyz>" at the top
>> level.
>
> As stated many many times (by me)... I'd really like the XSLT to take
> care of all of these things and slowly trim down our parser.
>
> Mika - does the XSLT library that we use have the ability to load
> multiple stylesheets? Can we have a "common functions" XSLT file that
> contains date parsing and other things we need in multiple files?

At least on Linux it does work properly. Just to make sure that it
works on other environments as well, here is a patch with the datetime
conversion moved to a separate file. It should be tested on Windows
and Mac before moving any of the common functions (or templates) to
this separate file.

>>> It would be easy to split the datetime field to separate date and time
>>> fields in XSLT. Any possible timezone information would be quite a bit
>>> harder to take into account properly.. However, all the samples I have
>>> contain the time in simple universal format.
>>
>> The datetime format (aka ISO 8601) is what the various files on the
>> internet seem to have. The DR5 uddf files do the
>> <date><hour>12</hour>... thing. I've never seen anything that has a
>> timezone, but anything is possible, I guess.
>
> Timezone handling would be a pain if it is done by name, but as long as
> it is just an offset we should IGNORE it - we always simply store
> localtime.

The attached patch ignores any time zone information. However, it does
not implement the standard fully as it basically ignores the case when
e.g. day or minute and second are missing from the datatime field.
(Missing seconds is handled by subsurface well enough, even with the
trailing colon like 20:31:)

miika
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Parse-ISO-8601-time-format.patch
Type: application/octet-stream
Size: 4147 bytes
Desc: not available
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20130227/e2d86326/attachment-0001.obj>