That all makes a lot of sense, I was never clear on why we coerced them
into GMT.
That leaves the JDBC date test case - I think that if we stop forcing dates
into GMT then it will go back to working east of Greenwich as the DB will
be created in the local time zone - I'll try and have a look this week.
Ian
On Sat, Apr 18, 2015 at 8:50 PM Andrea Aime <andrea.a...@geo-solutions.it>
wrote:
> On Sat, Apr 18, 2015 at 8:01 PM, Andrea Aime <andrea.a...@geo-solutions.it
> > wrote:
>
>> in GMT before insterting them in the database, which is probably going to
>> be used by other applications too?
>> What if the other apps are not timezone savvy, or what if your database
>> does not have a timestamp with timezone
>> field?
>>
>
> Thinking a bit more about it, two examples:
> * We are reading an already existing table in a database, the drivers
> gives us a Date object. What timezone is it in?
> The JVM default one
> * When we are converting the Date objects in strings, using those
> formatters that force the date in GMT, what is
> the formatter doing? Taking a Date object, which has no timezone of its
> own, assuming it's in the JVM timezone
> (cannot really be otherwise), and then converting it to GMT.
>
> I'm convinced that forcing GMT is the wrong way to go, the right
> assumption is already in the JVM, java.*.Date
> objects already supposed to be in the JVM default time zone.
> The problem is in the date->string converters that are geared towards GML
> usage, that force a GMT representation
> of the dates.
> And those are wrong too, because GML can represent dates in whatever time
> zone, I believe they are setup
> that way because the CITE tests are checking for dates in GMT.
>
> Imho, if you are working in an application that spans timezones, large
> area, eventually worldwide, you setup
> your systems and JVM to run on GMT (like I normally see them in these
> occasions) and naturally expect
> all dates in that timezone.
>
> If you are working in a local application instead, everything is running
> in your local timezone,and everything,
> including GML, should be in that timezone, and correctly reflect it,
> instead of being coerced to GMT, e.g.:
>
> <gml:beginPosition>2011-04-04T00:00:00-05:00</gml:beginPosition>
>
> So... I believe we should remove all the bits that are forcing an
> innatural time zone, and for the specific of the GeoServer CITE tests,
> we should probably just document that the JVM must be set in GMT
>
> Cheers
> Andrea
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/NWWaa2 for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39 339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be confidential or
> proprietary in nature or covered by the provisions of privacy act
> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
> Code).Any use not in accord with its purpose, any disclosure, reproduction,
> copying, distribution, or either dissemination, either whole or partial, is
> strictly forbidden except previous formal approval of the named
> addressee(s). If you are not the intended recipient, please contact
> immediately the sender by telephone, fax or e-mail and delete the
> information in this message that has been received in error. The sender
> does not give any warranty or accept liability as the content, accuracy or
> completeness of sent messages and accepts no responsibility for changes
> made after they were sent or for other risks which arise as a result of
> e-mail transmission, viruses, etc.
>
> -------------------------------------------------------
>
------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
