jira.codehaus.org

  • Log In Access more options
    • Online Help
    • Keyboard Shortcuts
    • About JIRA
    • JIRA Credits
    • What?s New
  • Dashboards Access more options (Alt+d)
  • Projects Access more options (Alt+p)
  • Issues Access more options (Alt+i)
Signup
GeoServer
  • GeoServer
  • GEOS-378

DateTime

  • Log In
  • Views
    • XML
    • Word
    • Printable

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    0

Description

F.Zuriaga emailed this report. I think this might be related to some of the Date/Time stuff that Paolo has recently fixed/looked at.

Hello, I have a problem with the DateTime format. I use a postgis data base,
and the table has a DateTime field. But I don't want to receibe this
attribute.
The problem is that I can't select the attributes of features to receibe,
WFS always send ALL attributes for the features.

<?xml version="1.0" encoding="UTF-8"?>
<GetFeature xmlns="http://www.opengis.net/wfs"
xmlns:gml="http://www.opengis.net/gml"
xmlns:ogc="http://www.opengis.net/ogc" version="1.0.0" service="WFS"
outputFormat="GML2">
<Query typeName="elFerGis:usuarios">
<ogc:PropertyName>elFerGis:nombre</ogc:PropertyName>
<ogc:PropertyName>elFerGis:dinero</ogc:PropertyName>
<ogc:PropertyName>elFerGis:password</ogc:PropertyName>
</Query>
</GetFeature>

Thanks in advanced:
F.Zuriaga

Issue Links

relates to

Bug - A problem which impairs or prevents the functions of the product. GEOS-311 Date-Attributes in requests and responses should have xs:dateTime / xs:date format

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
  • All
  • Comments
  • Work Log
  • History
  • Activity
Hide
Permalink
dblasby added a comment - 30/Sep/05 2:59 PM

this is more complicated that you might think. You have to make sure you can tell the difference between date & date-and-time types.

Show
dblasby added a comment - 30/Sep/05 2:59 PM this is more complicated that you might think. You have to make sure you can tell the difference between date & date-and-time types.
Hide
Permalink
dblasby added a comment - 26/Oct/05 12:09 AM

This is gonna take a while to change - need to talk to the geotools PMC about it.

Show
dblasby added a comment - 26/Oct/05 12:09 AM This is gonna take a while to change - need to talk to the geotools PMC about it.
Hide
Permalink
dblasby added a comment - 07/Dec/05 4:14 AM

Another user issue... (GFleming@csir.co.za).

I'm using Geoserver to serve points stored in PostGIS with time fields of type 'timestamp with timezone', with the timezone = +02 (being South African Standard Time).

If I query them in psql or do a WMS GetFeatureInfo through MapServer, the response represents the time correctly, by including the time zone.

GeoServer, however, returns the time minus 2h, with no indication of time zone. So it appears as if the times are two hours out. I would expect it either to return the time as is like MapServer does, or to subtract to hours and reflect that the time shown is now UTC.

Is there something I need to do to get around this or is it a geoserver issue?

Gavin

–

Show
dblasby added a comment - 07/Dec/05 4:14 AM Another user issue... (GFleming@csir.co.za). I'm using Geoserver to serve points stored in PostGIS with time fields of type 'timestamp with timezone', with the timezone = +02 (being South African Standard Time). If I query them in psql or do a WMS GetFeatureInfo through MapServer, the response represents the time correctly, by including the time zone. GeoServer, however, returns the time minus 2h, with no indication of time zone. So it appears as if the times are two hours out. I would expect it either to return the time as is like MapServer does, or to subtract to hours and reflect that the time shown is now UTC. Is there something I need to do to get around this or is it a geoserver issue? Gavin –
Hide
Permalink
Justin Deoliveira added a comment - 22/Dec/05 8:36 PM

moving to 1.3.1

Show
Justin Deoliveira added a comment - 22/Dec/05 8:36 PM moving to 1.3.1
Hide
Permalink
dblasby added a comment - 28/Dec/05 5:52 AM

justin - please have a look at this and write a little "ideas on how to fix" for 1.3.0. This is a major issue that should be fixed for 1.3.0, but it should be okay to wait until 1.3.1. But, I'd like someone to at least look at it before 1.3.0 is put out.

You can immediately see the problem if you add time, date-time, time with timezone, date (without time), etc... types to a postgis table. Then look at the GML output. The opposite direction (ie. update or insert) from GML to postgis has the same issues. I think its simply to "buff-up" the temporal type so it has more morphs and knows how to convert between them.

NOTE: I think there are some minor differences between postgresql types and the standard SQL-92 definitions. If we hit SQL-92 we should be able to pickup all the other databases in one swoop too (oracle and DB2 - dont know the mysql status).

Ask chris about it – we added a patch that was supposed to make this less of a problem, but it broke cite tests so we rolled it back. I believe the problem with it was that it converted the temporal datatype (a date-without-time) to a 'full' date-with-time-and-timezone type. That changed the GML representation from something like "2005-12-25" to one with time and timezone. The cite tests expect the simplified version.

If you just get a discussion going on the geotools devel list that would be great - no need to write any code for 1.3.0.

Show
dblasby added a comment - 28/Dec/05 5:52 AM justin - please have a look at this and write a little "ideas on how to fix" for 1.3.0. This is a major issue that should be fixed for 1.3.0, but it should be okay to wait until 1.3.1. But, I'd like someone to at least look at it before 1.3.0 is put out. You can immediately see the problem if you add time, date-time, time with timezone, date (without time), etc... types to a postgis table. Then look at the GML output. The opposite direction (ie. update or insert) from GML to postgis has the same issues. I think its simply to "buff-up" the temporal type so it has more morphs and knows how to convert between them. NOTE: I think there are some minor differences between postgresql types and the standard SQL-92 definitions. If we hit SQL-92 we should be able to pickup all the other databases in one swoop too (oracle and DB2 - dont know the mysql status). Ask chris about it – we added a patch that was supposed to make this less of a problem, but it broke cite tests so we rolled it back. I believe the problem with it was that it converted the temporal datatype (a date-without-time) to a 'full' date-with-time-and-timezone type. That changed the GML representation from something like "2005-12-25" to one with time and timezone. The cite tests expect the simplified version. If you just get a discussion going on the geotools devel list that would be great - no need to write any code for 1.3.0.
Hide
Permalink
Justin Deoliveira added a comment - 19/Feb/07 12:25 PM

Date and date time support has been substantially improved in geotools 2.4 / geoserver 1.6, pushing off to 1.6.x

Show
Justin Deoliveira added a comment - 19/Feb/07 12:25 PM Date and date time support has been substantially improved in geotools 2.4 / geoserver 1.6, pushing off to 1.6.x
Hide
Permalink
Andrea Aime added a comment - 04/Dec/09 4:21 AM

As far as I know this has been fixed. Reopen if I'm missing anything

Show
Andrea Aime added a comment - 04/Dec/09 4:21 AM As far as I know this has been fixed. Reopen if I'm missing anything

People

  • Assignee:
    Justin Deoliveira
    Reporter:
    dblasby
Vote (0)
Watch (0)

Dates

  • Created:
    15/Jul/05 2:14 PM
    Updated:
    08/Dec/10 3:34 AM
    Resolved:
    04/Dec/09 4:21 AM
  • Atlassian JIRA (v5.2.7#850-sha1:b2af0c8)
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.