[Geoserver-devel] global timezone setting

GeoServer GeoServer Developer
,
1

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.

2

On Sat, Oct 15, 2011 at 12:08 AM, Ian Schneider <ischneider@anonymised.com…1501…> wrote:

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).

I agree the timezone situation is handled in a poor way so far and needs
improvement.
But I not sure forcing UTC as the default will be beneficial, I think it depends.
In order to elaborate, we need to talk about where time is used and the kind
of application we have in mind.

Timezone might affect:

  • how time data in the stores is interpreted
  • how time information is returned back to the user
  • how time literals in the filters/slds are parsed

In a perfect would all time information would come with a timezone attached,
but we already know that it’s not like that. Often people did not care because
there was a obvious default (but such default comes with the territory,
more on this later).

Stores like shapefile has a default timezone since time data there does not
have any timezone attached (sorry about the config issue, we used shapefiles
for time only as raster mosaic indexes and there the timezone is specified
out of the GeoServer config).

Databases often have timestamp with a timezone, but it’s now always used.
It might be useful to be able to specify a default timezone there too…
as a store parameter? Probably, though in some more hairy cases a
timezone per table might be necessary (I would be inclined to tell the user
to fix her data management, but maybe they have good reasons).

I guess the same might be applied to any other store (e.g., cascaded wfs?).

Once we know in what timezone the data is we can decide in what timezone
we want to advertise the data.
This is a bit hairy too, I guess we have a choice between using the data timezone
and UTC (and if they differ, perform a conversion on the fly?).

Then we have incoming filters talking time. XML date/time has the option
to specify a timezone, but what to do if it has not been specified?
I’d say, use the same default applied to the data we are returning (data
native vs UTC) for consistency, so that we filter in the same timezone the
data is returned.

Now, is UTC a good global default? If my application deals with united nations,
military, wheather forecast, and scientific wide area studies, it naturally does.
Mind, this people will automatically wonder about the time zone and setup
proper default, because dealing multiple timezones is part of their job.

However any restricted area application working at less than a single state level,
with an audience which is mostly local, will definitely assume local timezone
and using any other default will confuse the heck out of them, both users,
developers and administrator: timezone shifts and UTC are way out of their
normal way of thinking about itme.

Point in case, say I make an application to manage public parks in NY and
part of the information attached to parks is events taking place in the park,
or opening times, do you think anyone would be interested in times/dates
in UTC? Or that they would even consider the possibility they are in UTC?
We’d end up with people looking for the farmer market at 3am in the night :slight_smile:

Long story short, there is a lot of potential users that do not think about timezones
that might be very surprised about UTC being the default, especially so since
they are not even considering the problem.

That’s why, while being very pro having good control over timezones at all
levels so that the server has a consistent story about, I’m also convinced
UTC by default might create a lot of chaos.
Btw, it would also make for a bad backwards compatibility story, “hey, I just
upgraded GeoSeever to the lastest version and now all my dates/times went pear shaped!”

Can we have some sort of easy to set default, but at the same time keep the
local timezone as the default in all places where the OGX standard does not
say to use UTC?

Cheers
Andrea

–

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf