It would be super nice if geoserver had a global time zone setting that could be applied to all datastores (part 2 of this conversation - implementing a time zone parameter in geotools datastores and choosing reasonable defaults).
The idea would be that the default would be UTC - after all, if you have data that may originate in one timezone and clients in others, the only sane way to handle data externally (and therefore internally) is UTC (like how WMS getcaps does it). I cannot find any arguments for non UTC behavior, so someone speak up. I don't understand all of the implications regarding other aspects of geoserver (so please chime in), but the WMS time functionality has some problems. There are several places where this shows up as a problem in the current geoserver/geotools: 1) Date fields read from shapefile datastores are interpreted using local time zone (unless one is specified and there is no UI for this yet) except due to https://jira.codehaus.org/browse/GEOS-4801, they are actually not at some point (making things really confusing) 2) timestamp database types without timezone are interpreted using local time zone. Though this could be seen as a data integrity issue, the current datatype selected when transforming a featuretype using geotools is timestamp without timezone (at least for postgis). 3) the WMS getcaps DimensionHelper correctly formats Date objects to UTC and the getmap request correctly takes them in as UTC, but this causes a miss when data in case 2 is present as the JDBC filter then fails. For the sake of sanity, coming up with some rules on how to handle user dates and timestamps would benefit many, I'm guessing. Assuming we stick with an internal representation of Date (which actually implies UTC), my thoughts: 1) Global default timezone is UTC 2) All user data is internally represented as UTC (probably already true) 3) For non-time stamped user data (dates, timestamp w/out tz), assume the global default timezone or allow for an override on a store-by-store basis (for some use case I'm not aware of) 4) Server time still uses JVM default (the global default I mention is geoserver specific) 5) Client representation is not covered here (nor by the current WMS getcaps) I'm working on the JDBC implementation now and already submitted a patch for GEOS-4801 (actually a geotools patch). This problem took a long time to wrap my head around, partly because GEOS-4801 made me go slightly crazy as I was witnessing differing behavior, mostly because timezones suck - feedback much appreciated. Reference Material: Well written low-down: http://www.odi.ch/prog/design/datetime.php Postgres : http://www.postgresql.org/docs/8.4/static/datatype-datetime.html#DATATYPE-TIMEZONES Another : http://postgresql.1045698.n5.nabble.com/Timestamp-confusion-td2174087.html Cheers, -Ian -- Ian Schneider OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
