[Geoserver-devel] We're generating invalid dates in GML....

Andrea_Aime3 · March 6, 2007, 4:40pm

Hi,
it seems my little versioned datastore is issue happy...
This time I've discovered I'm not able to see the changesets feature type (which is really the versioned data store log table) in udig
from WFS.

Now, uDig reports parsing errors on a date field, and in fact something
is going on because XML validation of the generated GML does not pass.

Here is the feature type:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="http://www.openplans.org/topp"
   xmlns:topp="http://www.openplans.org/topp"
   xmlns:gml="http://www.opengis.net/gml"
   xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"
   attributeFormDefault="unqualified" version="1.0">
   <xs:import namespace="http://www.opengis.net/gml"
schemaLocation="http://localhost:8080/geoserver/schemas/gml/2.1.2/feature.xsd" />
   <xs:complexType xmlns:xs="http://www.w3.org/2001/XMLSchema"
     name="changesets_Type">
     <xs:complexContent>
       <xs:extension base="gml:AbstractFeatureType">
         <xs:sequence>
           <xs:element name="author" minOccurs="0" nillable="true">
             <xs:simpleType>
               <xs:restriction base="xs:string">
                 <xs:maxLength value="2147483647" />
               </xs:restriction>

             </xs:simpleType>
           </xs:element>
           <xs:element name="date" minOccurs="0" nillable="true"
             type="xs:dateTime" />
           <xs:element name="message" minOccurs="0" nillable="true">
             <xs:simpleType>
               <xs:restriction base="xs:string">
                 <xs:maxLength value="2147483647" />
               </xs:restriction>
             </xs:simpleType>

           </xs:element>
           <xs:element name="BBOX" minOccurs="0" nillable="true"
             type="gml:PolygonPropertyType" />
         </xs:sequence>
       </xs:extension>
     </xs:complexContent>
   </xs:complexType>
   <xs:element name='changesets' type='topp:changesets_Type'
     substitutionGroup='gml:_Feature' />
</xs:schema>

and here is a sample feature:

<gml:featureMember>
     <topp:changesets fid="1">
       <topp:date>2007-03-05 15:38:57.046</topp:date>
       <topp:message>Version enabling archsites</topp:message>
       <topp:BBOX>
         <gml:Polygon srsName="http://www.opengis.net/gml/srs/epsg.xml#4326">
           <gml:outerBoundaryIs>
             <gml:LinearRing>
               <gml:coordinates decimal="." cs="," ts=" ">
                 -103.87256377,44.37740325 -103.6379418,44.37740325
                 -103.6379418,44.48804274 -103.87256377,44.48804274
                 -103.87256377,44.37740325
               </gml:coordinates>
             </gml:LinearRing>
           </gml:outerBoundaryIs>
         </gml:Polygon>
       </topp:BBOX>
     </topp:changesets>
   </gml:featureMember>

Oh hum. om fact "2007-03-05 15:38:57.046" is not a valid xs:dateTime.
The valid pattern (http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#dateTime)
is CCYY-MM-DDThh:mm:ss, so no milliseconds around, and we need the T, not a space.

I'm wondering if this problem came up before and how it was dealt with,
and if the new GML2 bindings would do the right thing.

Cheers
Andrea

Justin_Deoliveira · March 6, 2007, 4:54pm

Hmmm, I am surprised the wfs 1.0 cite tests pass as they do a lot of
testing against dates... But i guess that is just date and not datetime
so that makes sense.

The 1.1 tests do have some dateTime data, and I am pretty sure the new
gml bindings ( both gml2 and gml3 since they use the same binding for
dateTime ) will handle these properly.

Using gtxml for gml encoding is being used for wfs 1.1, but not for wfs
1.0. I just never really had a need to since for gml2 the old
transformer stuff works fine ( for non date time perhaps ). However
switching over would not be much work.

-Justin

Andrea Aime wrote:

Hi,
it seems my little versioned datastore is issue happy...
This time I've discovered I'm not able to see the changesets feature
type (which is really the versioned data store log table) in udig
from WFS.

Now, uDig reports parsing errors on a date field, and in fact something
is going on because XML validation of the generated GML does not pass.

Here is the feature type:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="http://www.openplans.org/topp"
   xmlns:topp="http://www.openplans.org/topp"
   xmlns:gml="http://www.opengis.net/gml"
   xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
   attributeFormDefault="unqualified" version="1.0">
   <xs:import namespace="http://www.opengis.net/gml"

schemaLocation="http://localhost:8080/geoserver/schemas/gml/2.1.2/feature.xsd"
/>
   <xs:complexType xmlns:xs="http://www.w3.org/2001/XMLSchema"
     name="changesets_Type">
     <xs:complexContent>
       <xs:extension base="gml:AbstractFeatureType">
         <xs:sequence>
           <xs:element name="author" minOccurs="0" nillable="true">
             <xs:simpleType>
               <xs:restriction base="xs:string">
                 <xs:maxLength value="2147483647" />
               </xs:restriction>

             </xs:simpleType>
           </xs:element>
           <xs:element name="date" minOccurs="0" nillable="true"
             type="xs:dateTime" />
           <xs:element name="message" minOccurs="0" nillable="true">
             <xs:simpleType>
               <xs:restriction base="xs:string">
                 <xs:maxLength value="2147483647" />
               </xs:restriction>
             </xs:simpleType>

           </xs:element>
           <xs:element name="BBOX" minOccurs="0" nillable="true"
             type="gml:PolygonPropertyType" />
         </xs:sequence>
       </xs:extension>
     </xs:complexContent>
   </xs:complexType>
   <xs:element name='changesets' type='topp:changesets_Type'
     substitutionGroup='gml:_Feature' />
</xs:schema>

and here is a sample feature:

<gml:featureMember>
     <topp:changesets fid="1">
       <topp:date>2007-03-05 15:38:57.046</topp:date>
       <topp:message>Version enabling archsites</topp:message>
       <topp:BBOX>
         <gml:Polygon
srsName="http://www.opengis.net/gml/srs/epsg.xml#4326">
           <gml:outerBoundaryIs>
             <gml:LinearRing>
               <gml:coordinates decimal="." cs="," ts=" ">
                 -103.87256377,44.37740325 -103.6379418,44.37740325
                 -103.6379418,44.48804274 -103.87256377,44.48804274
                 -103.87256377,44.37740325
               </gml:coordinates>
             </gml:LinearRing>
           </gml:outerBoundaryIs>
         </gml:Polygon>
       </topp:BBOX>
     </topp:changesets>
   </gml:featureMember>

Oh hum. om fact "2007-03-05 15:38:57.046" is not a valid xs:dateTime.
The valid pattern
(http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#dateTime)
is CCYY-MM-DDThh:mm:ss, so no milliseconds around, and we need the T,
not a space.

I'm wondering if this problem came up before and how it was dealt with,
and if the new GML2 bindings would do the right thing.

Cheers
Andrea

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:1004,45ed9bb93871995013331!

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

Jesse_Eichar1 · March 6, 2007, 5:05pm

I'm curious if it is a uDig problem or a Geoserver problem. I remember someone mentioning Dates not being correctly handled by the WFS Client, but I don't know if it was ever addressed. It was before I entered the WFS battlefield.

Jesse

On 6-Mar-07, at 8:40 AM, Andrea Aime wrote:

Hi,
it seems my little versioned datastore is issue happy...
This time I've discovered I'm not able to see the changesets feature type (which is really the versioned data store log table) in udig
from WFS.

Now, uDig reports parsing errors on a date field, and in fact something
is going on because XML validation of the generated GML does not pass.

Here is the feature type:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="http://www.openplans.org/topp"
  xmlns:topp="http://www.openplans.org/topp"
  xmlns:gml="http://www.opengis.net/gml"
  xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"
  attributeFormDefault="unqualified" version="1.0">
  <xs:import namespace="http://www.opengis.net/gml"
schemaLocation="http://localhost:8080/geoserver/schemas/gml/2.1.2/feature.xsd" />
  <xs:complexType xmlns:xs="http://www.w3.org/2001/XMLSchema"
    name="changesets_Type">
    <xs:complexContent>
      <xs:extension base="gml:AbstractFeatureType">
        <xs:sequence>
          <xs:element name="author" minOccurs="0" nillable="true">
            <xs:simpleType>
              <xs:restriction base="xs:string">
                <xs:maxLength value="2147483647" />
              </xs:restriction>

            </xs:simpleType>
          </xs:element>
          <xs:element name="date" minOccurs="0" nillable="true"
            type="xs:dateTime" />
          <xs:element name="message" minOccurs="0" nillable="true">
            <xs:simpleType>
              <xs:restriction base="xs:string">
                <xs:maxLength value="2147483647" />
              </xs:restriction>
            </xs:simpleType>

          </xs:element>
          <xs:element name="BBOX" minOccurs="0" nillable="true"
            type="gml:PolygonPropertyType" />
        </xs:sequence>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>
  <xs:element name='changesets' type='topp:changesets_Type'
    substitutionGroup='gml:_Feature' />
</xs:schema>

and here is a sample feature:

<gml:featureMember>
    <topp:changesets fid="1">
      <topp:date>2007-03-05 15:38:57.046</topp:date>
      <topp:message>Version enabling archsites</topp:message>
      <topp:BBOX>
        <gml:Polygon srsName="http://www.opengis.net/gml/srs/epsg.xml#4326">
          <gml:outerBoundaryIs>
            <gml:LinearRing>
              <gml:coordinates decimal="." cs="," ts=" ">
                -103.87256377,44.37740325 -103.6379418,44.37740325
                -103.6379418,44.48804274 -103.87256377,44.48804274
                -103.87256377,44.37740325
              </gml:coordinates>
            </gml:LinearRing>
          </gml:outerBoundaryIs>
        </gml:Polygon>
      </topp:BBOX>
    </topp:changesets>
  </gml:featureMember>

Oh hum. om fact "2007-03-05 15:38:57.046" is not a valid xs:dateTime.
The valid pattern (http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#dateTime)
is CCYY-MM-DDThh:mm:ss, so no milliseconds around, and we need the T, not a space.

I'm wondering if this problem came up before and how it was dealt with,
and if the new GML2 bindings would do the right thing.

Cheers
Andrea
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel

Andrea_Aime3 · March 6, 2007, 5:11pm

Justin Deoliveira ha scritto:

Hmmm, I am surprised the wfs 1.0 cite tests pass as they do a lot of
testing against dates... But i guess that is just date and not datetime
so that makes sense.

Hmm... that's suprising nonetheless... attributes encoding in Geotools
FeatureTranslator is handled in FeatureTranslator.handleAttribute:

if (Geometry.class.isAssignableFrom(value.getClass())) {
     geometryTranslator.encode((Geometry) value, srsName);
} else {
     String text = value.toString();
     contentHandler.characters(text.toCharArray(), 0,
         text.length());
}

Sooo.... it seems to me it was working only because of sheer luck?

Looking at the FeatureTypeEncoder, every subclass of java.util.Date
will be turned into a xs:datetime, so I guess wfs 1.0 passed only
because we use Postgis as the backing store, which was configured
to use a date type, and returned as a result a java.sql.Date that
toStrings to something which is in the format CCYY-MM-dd, apparently
another format supported by xs:datetime.

Cheers
Andrea

Justin_Deoliveira · March 6, 2007, 5:19pm

Yup. The new bindings use the jaxb data binding classes to specifically
serialize as xml.

Andrea Aime wrote:

Justin Deoliveira ha scritto:

Hmmm, I am surprised the wfs 1.0 cite tests pass as they do a lot of
testing against dates... But i guess that is just date and not datetime
so that makes sense.

Hmm... that's suprising nonetheless... attributes encoding in Geotools
FeatureTranslator is handled in FeatureTranslator.handleAttribute:

if (Geometry.class.isAssignableFrom(value.getClass())) {
     geometryTranslator.encode((Geometry) value, srsName);
} else {
     String text = value.toString();
     contentHandler.characters(text.toCharArray(), 0,
         text.length());
}

Sooo.... it seems to me it was working only because of sheer luck?

Looking at the FeatureTypeEncoder, every subclass of java.util.Date
will be turned into a xs:datetime, so I guess wfs 1.0 passed only
because we use Postgis as the backing store, which was configured
to use a date type, and returned as a result a java.sql.Date that
toStrings to something which is in the format CCYY-MM-dd, apparently
another format supported by xs:datetime.

Cheers
Andrea

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:1004,45eda27113981116498154!

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

Chris_Holmes1 · March 6, 2007, 6:25pm

Hmmm... I thought we had at least modified toString to at least give consistent output, but it looks like that is not the case.

There's this DateUtil class in the codebase: http://svn.geotools.org/geotools/branches/2.3.x/module/main/src/org/geotools/feature/type/DateUtil.java

That handles W3C dates and times, but it appears we're not using it in the code at all.

It sounds like we should fix either the encoder or the toString to do a bit better than it does now.

Chris

Andrea Aime wrote:

Justin Deoliveira ha scritto:

Hmmm, I am surprised the wfs 1.0 cite tests pass as they do a lot of
testing against dates... But i guess that is just date and not datetime
so that makes sense.

Hmm... that's suprising nonetheless... attributes encoding in Geotools
FeatureTranslator is handled in FeatureTranslator.handleAttribute:

if (Geometry.class.isAssignableFrom(value.getClass())) {
     geometryTranslator.encode((Geometry) value, srsName);
} else {
     String text = value.toString();
     contentHandler.characters(text.toCharArray(), 0,
         text.length());
}

Sooo.... it seems to me it was working only because of sheer luck?

Looking at the FeatureTypeEncoder, every subclass of java.util.Date
will be turned into a xs:datetime, so I guess wfs 1.0 passed only
because we use Postgis as the backing store, which was configured
to use a date type, and returned as a result a java.sql.Date that
toStrings to something which is in the format CCYY-MM-dd, apparently
another format supported by xs:datetime.

Cheers
Andrea

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:1003,45eda27413931365099012!

--
Chris Holmes
The Open Planning Project
http://topp.openplans.org

Andrea_Aime3 · March 6, 2007, 7:00pm

Chris Holmes ha scritto:

Hmmm... I thought we had at least modified toString to at least give consistent output, but it looks like that is not the case.

There's this DateUtil class in the codebase: http://svn.geotools.org/geotools/branches/2.3.x/module/main/src/org/geotools/feature/type/DateUtil.java

That handles W3C dates and times, but it appears we're not using it in the code at all.

It sounds like we should fix either the encoder or the toString to do a bit better than it does now.

Yahoo!!!!! I was looking around for such a class, and came up with jaxb and jaxme, but this one is already there and has no license issues

Cheers
Andrea

Gertjan_van_Oosten · March 7, 2007, 11:44am

Hi Andrea,

As quoted from Andrea Aime <aaime@anonymised.com>:

Oh hum. om fact "2007-03-05 15:38:57.046" is not a valid xs:dateTime.
The valid pattern
(http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#dateTime)
is CCYY-MM-DDThh:mm:ss, so no milliseconds around,

You missed the sentence on the URL above where it says:

  "Additional digits can be used to increase the precision of fractional
   seconds if desired i.e the format ss.ss... with any number of digits
   after the decimal point is supported. The fractional seconds part is
   optional; other parts of the lexical form are not optional."

and we need the T, not a space.

And frankly, I prefer if it were in UTC, so an additional Z at the end.

Regards,
--
-- Gertjan van Oosten, gertjan@anonymised.com, West Consulting B.V., +31 15 2191 600

Andrea_Aime3 · March 7, 2007, 1:07pm

Gertjan van Oosten ha scritto:

Hi Andrea,

As quoted from Andrea Aime <aaime@anonymised.com>:

Oh hum. om fact "2007-03-05 15:38:57.046" is not a valid xs:dateTime.
The valid pattern (http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#dateTime)
is CCYY-MM-DDThh:mm:ss, so no milliseconds around,

You missed the sentence on the URL above where it says:

  "Additional digits can be used to increase the precision of fractional
   seconds if desired i.e the format ss.ss... with any number of digits
   after the decimal point is supported. The fractional seconds part is
   optional; other parts of the lexical form are not optional."

and we need the T, not a space.

Hum, with the latest fixes we're generating:
2007-03-05T14:38:57.046

I have an option to include the Z marker (but afaik it just appends a Z, it's not like it's doing any time zone conversion). Any reason for asking that one? I guess we should make this configurable.

Cheers
Andrea

Gertjan_van_Oosten · March 7, 2007, 1:48pm

As quoted from Andrea Aime <aaime@anonymised.com>:

Hum, with the latest fixes we're generating:
2007-03-05T14:38:57.046

I have an option to include the Z marker (but afaik it just appends a Z,
it's not like it's doing any time zone conversion). Any reason for
asking that one?

Because that's a way of being sure which timezone the given time is in.
Otherwise one would have to guess what the timezone is of the server
that serves the datasource.

I guess we should make this configurable.

That would suit me just fine. Alternate timezone specifications would
also be OK:

  "This representation may be immediately followed by a "Z" to indicate
   Coordinated Universal Time (UTC) or, to indicate the time zone, i.e.
   the difference between the local time and Coordinated Universal Time,
   immediately followed by a sign, + or -, followed by the difference
   from UTC represented as hh:mm (note: the minutes part is required)."

Ideally the time would always be uniquely represented (i.e. *with* a
timezone given) to avoid errors in timezone assumptions. I may be
looking at a feature with a timestamp served from a server somewhere on
the Internet without knowing the local timezone of that server (it may
not even be possible to know that, the server could be misconfigured).
I really, really should be able to rely on the timestamp alone.

Kind regards,
--
-- Gertjan van Oosten, gertjan@anonymised.com, West Consulting B.V., +31 15 2191 600

Andrea_Aime3 · March 8, 2007, 1:26pm

Gertjan van Oosten ha scritto:

I guess we should make this configurable.

That would suit me just fine. Alternate timezone specifications would
also be OK:

  "This representation may be immediately followed by a "Z" to indicate
   Coordinated Universal Time (UTC) or, to indicate the time zone, i.e.
   the difference between the local time and Coordinated Universal Time,
   immediately followed by a sign, + or -, followed by the difference
   from UTC represented as hh:mm (note: the minutes part is required)."

Ideally the time would always be uniquely represented (i.e. *with* a
timezone given) to avoid errors in timezone assumptions. I may be
looking at a feature with a timestamp served from a server somewhere on
the Internet without knowing the local timezone of that server (it may
not even be possible to know that, the server could be misconfigured).
I really, really should be able to rely on the timestamp alone.

I see. I'll have to change the way our code behaves to make it publish
the proper offset, since now there is just an option to add a "Z" at
the end of the string, but it does not really converts the date
to the UTC timezone.

Hum, I don't have time to work on this now, but I've opened an issue:
http://jira.codehaus.org/browse/GEOT-1193

If you feel like providing a patch, DateUtil is here:
http://svn.geotools.org/geotools/trunk/gt/modules/library/main/src/main/java/org/geotools/feature/type/DateUtil.java

and the relevant methods are serializeDateTime and parseDateTime (and
probably serializeTime, serializeSqlTime, and parseTime too)

Cheers
Andrea

Gertjan_van_Oosten · June 22, 2007, 9:13am

Hi Andrea e.a.,

Gertjan van Oosten ha scritto:
> "This representation may be immediately followed by a "Z" to indicate
> Coordinated Universal Time (UTC) or, to indicate the time zone, i.e.
> the difference between the local time and Coordinated Universal Time,
> immediately followed by a sign, + or -, followed by the difference
> from UTC represented as hh:mm (note: the minutes part is required)."
>
> Ideally the time would always be uniquely represented (i.e. *with* a
> timezone given) to avoid errors in timezone assumptions. I may be
> looking at a feature with a timestamp served from a server somewhere on
> the Internet without knowing the local timezone of that server (it may
> not even be possible to know that, the server could be misconfigured).
> I really, really should be able to rely on the timestamp alone.

It's even worse: retrieving a feature and then saving it *unchanged*
modifies the timestamp. This is with Geoserver-1.5.1 and a PostGIS data
store. Example:

Retrieved feature:

  <gml:featureMember>
    <west:features fid="features.193">
      <west:name>West Consulting</west:name>
      <west:geom>
        <gml:Point srsName="http://www.opengis.net/gml/srs/epsg.xml#4326">
          <gml:coordinates xmlns:gml="http://www.opengis.net/gml" decimal="." cs="," ts=" ">4.38160,51.99710</gml:coordinates>
        </gml:Point>
      </west:geom>
      <west:timestamp>2007-06-22T03:48:00</west:timestamp>
    </west:features>
  </gml:featureMember>

Update transaction:

  <wfs:Transaction xmlns:wfs="http://www.opengis.net/wfs" service="WFS" version="1.0.0">
    <wfs:Update typeName="west:features">
      <ogc:Filter xmlns:ogc="http://www.opengis.net/ogc">
        <ogc:FeatureId fid="features.193"/>
      </ogc:Filter>
      <wfs:Property>
        <wfs:Name>west:name</wfs:Name>
        <wfs:Value>West Consulting</wfs:Value>
      </wfs:Property>
      <wfs:Property>
        <wfs:Name>west:geom</wfs:Name>
        <wfs:Value>
          <gml:Point xmlns:gml="http://www.opengis.net/gml" srsName="http://www.opengis.net/gml/srs/epsg\.xml\#4326">
            <gml:coordinates xmlns:gml="http://www.opengis.net/gml" decimal="." cs="," ts=" ">4.38160,51.99710</gml:coordinates>
          </gml:Point>
        </wfs:Value>
      </wfs:Property>
      <wfs:Property>
        <wfs:Name>west:timestamp</wfs:Name>
        <wfs:Value>2007-06-22T03:48:00</wfs:Value>
      </wfs:Property>
    </wfs:Update>
  </wfs:Transaction>

Retrieved feature:

  <gml:featureMember>
    <west:features fid="features.193">
      <west:name>West Consulting</west:name>
      <west:geom>
        <gml:Point srsName="http://www.opengis.net/gml/srs/epsg.xml#4326">
          <gml:coordinates xmlns:gml="http://www.opengis.net/gml" decimal="." cs="," ts=" ">4.38160,51.99710</gml:coordinates>
        </gml:Point>
      </west:geom>
      <west:timestamp>2007-06-22T01:48:00</west:timestamp>
    </west:features>
  </gml:featureMember>

As you can see, the timestamp has shifted two hours into the past. This
is because currently our timezone offset is +2. Everytime I save the
feature the time shifts two hours back. That's not really acceptable
behaviour.

Hum, I don't have time to work on this now, but I've opened an issue:
http://jira.codehaus.org/browse/GEOT-1193

Can the priority for this issue be changed to Major? It's now over 3
months old and the current behaviour (with Geoserver-1.5.1 [1.4 does not
have this problem by the way]) is unacceptable to me.

Regards,
--
-- Gertjan van Oosten, gertjan@anonymised.com, West Consulting B.V., +31 15 2191 600

Andrea_Aime3 · June 22, 2007, 9:21am

Gertjan van Oosten ha scritto:

Hum, I don't have time to work on this now, but I've opened an issue:
http://jira.codehaus.org/browse/GEOT-1193

This one is not relevant to your issue afaik, it's just a matter of formatting.

Can the priority for this issue be changed to Major? It's now over 3
months old and the current behaviour (with Geoserver-1.5.1 [1.4 does not
have this problem by the way]) is unacceptable to me.

What you're experiencing is in my opinion http://jira.codehaus.org/browse/GEOS-1161, which has been fixed a few days ago. Can you grab a nightly from http://geo.openplans.org/nightly/1.5.x/ (the one generated June 21 should be fine) and check if you can still see the problem?
I'm pretty sure we fixed the GML generation side, but the parse side,
used in transaction, may still be broken.

Cheers
Andrea

Gertjan_van_Oosten · June 22, 2007, 9:57am

Hi Andrea,

As quoted from Andrea Aime <aaime@anonymised.com>:

What you're experiencing is in my opinion
http://jira.codehaus.org/browse/GEOS-1161, which has been fixed a few
days ago. Can you grab a nightly from
http://geo.openplans.org/nightly/1.5.x/ (the one generated June 21
should be fine) and check if you can still see the problem?

Well, what do you know? It *does* fix that problem!
Thanks for the quick response.

[Aside: I'd still like to see GEOT-1193 be fixed, it's quite impossible
to keep track of the different timezones of WFS's when combining
features from different sources.]

Regards,
--
-- Gertjan van Oosten, gertjan@anonymised.com, West Consulting B.V., +31 15 2191 600