Subject: RE: [Geopriv] Timezones in Civic locations

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 9 Apr 2006 18:07:00 -0500

Like Henning, this will be my last attempt to argue on this point.

My concerns with timezone introduction to the civic address are
summarized below.

1) It is information that is defined by existing presence
specifications. The remainder of the civic data is not.

2) It introduces a temporal aspect to the civic specification which in
not currently there. The argument that has been posed goes something
like "But +10 GMT specifies a location". For this to assist in
specifying location we need to have a convention of normal time, i.e.
daylight savings are never specified. Certainly this does not help the
argument of "I want to know if it is okay to contact them" since you do
not know if it is 8pm or 9pm. 

On the post code argument, to the best of my knowledge if I send a
letter with a post code attached it has a slim chance of getting to you,
if I exclude timezone can the same be said?

Andy, to be clear on what you are asking, you want a timezone specified
as an absolute from GMT that never includes daylight savings offsets or
indicators that the location may observe daylight savings?

Cheers
James

> -----Original Message-----
> From: Andrew Newton [mailto:[email-masked]]
> Sent: Saturday, 8 April 2006 9:22 AM
> To: Henning Schulzrinne
> Cc: 'GEOPRIV'
> Subject: Re: [Geopriv] Timezones in Civic locations
> 
> Henning Schulzrinne wrote:
> > (1) Timezone is uniquely determined if you can geocode, with
> > widely-available and public databases. They are derived information
in
> > exactly the same way that a PSAP is location-derived information.
> > According to your logic, we'd have to include the PSAP URL in the
civic
> > information as well since it has exactly the same properties.
> 
> The same is true of postal code.  Should we take it out?
> 
> > (2) As I stated before, the amount of location-derived information
that
> > could be included with locations is essentially infinite. Thus,
asking
> > 'why not' is not a useful discriminator. The question has to be
"which
> > information is necessary to enhance civic address information in the
two
> > primary purposes of message and people delivery."
> 
> In a working group where there have been no end of calls for expanding
> the charter, you have suddenly decided to narrow the scope of our work
> -- seemingly arbitrarily.  Is not an unreasonable thing to assume that
> the only part of location an entity may wish to convey is their
> timezone.  Many social networks allow participants to only convey
> continent information if they so desire.
> 
> >> derived -- meaning you cannot take the other components of the
civic
> >> location alone and determine the timezone or the postal code.
Sure,
> >
> > I've pointed out before that you can do this for timezones, assuming
you
> > can geocode to handle the odd cases like Sioux County. Geocoding is
> > insufficient for zip codes.
> 
> There are more than just a handful of odd cases and therefore straight
> algorithmic conversion is not possible.
> 
> -andy
> 
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Andrew Newton <[email-masked]>
Date: Mon, 10 Apr 2006 10:06:50 -0400

> if I exclude timezone can the same be said?

I'll be sure not to use postal codes when sending letters any more.  I 
had been under the assumption that they aided in the delivery of postal 
messages.  :)

Assuming you meant "without", I believe you are wrong.  At least in the 
US you can leave it off and the message will get delivered... it takes 
much longer, but it will get delivered.  Letters from my dear departed 
Grandmother use to get through all the time, and she consistently used 
the wrong postal code.

> indicators that the location may observe daylight savings?

Yes.  It has to be an absolute, otherwise you have a moving location 
which I admit is wrong.  If RPID is using timezone with DST, then there 
would be a difference between the two uses -- the RPID use would be for 
the calculation of local time whereas this use would be for the 
specification of location.

-andy

---

From: "Carl Reed OGC Account" <[email-masked]>
Date: Tue, 11 Apr 2006 10:00:58 -0600

Since this dialogue is continuing, I thought that it is a bit serendipitous 
that the OGC members are having similar dicussions! The following from a 
member email just this AM. The OGC is looking at a common and consistent 
approach for handling time zones for all of our web services type interface 
standards. The following has a bit of OGC speak in it, but the general 
information may be of use.

Cheers

Carl

The Time Zone representation in ISO 8601 (section 4.2.5 of
OWS Common) is consistent
with section 3.2.7.3 of the XML schema specification. Both of these
specifications state that time zones are represented as an offset to
Zulu/GMT, such as:

2002-10-10T12:00:00+05:00 is 2002-10-10T07:00:00Z and
2002-10-10T00:00:00+05:00 is 2002-10-09T19:00:00Z

What's missing in the OGC specs is some guidance on the usage of the
offset and how the services are to respond to it. When using temporal
queries, the hour/minute/second becomes quite meaningless if the service
isn't aware of local vs. zulu time offsets in the data being served. For
example, if I query a WFS for features between 2002-10-10T12:00:00 and
2002-10-10T18:00:00, what time zone is being requested? Zulu? Local Time
of client? Local time of the service? Furhtermore, what time offset will
be returned in the data? Misinterpretation of time offset can lead to
unintended results.

These questions should be understood without any ambiguity in order for
temporal queries to be used.
Yes, what I was recommending in 06-022 was the services to convert
between the time zone in the data and the time zone requested by the
client. If OWS common waits on the other services to implement this
capability first, then I should work on those change requests at the
same time. I thought OWS common was a good place to start since this
should be consistent across all services. Can you help facilitate this
change in multiple services?

----- Original Message ----- 
From: "Andrew Newton" <[email-masked]>
To: "Winterbottom, James" <[email-masked]>
Cc: "GEOPRIV" <[email-masked]>; "Henning Schulzrinne" 
<[email-masked]>
Sent: Monday, April 10, 2006 8:06 AM
Subject: Re: [Geopriv] Timezones in Civic locations

> I'll be sure not to use postal codes when sending letters any more.  I had 
> been under the assumption that they aided in the delivery of postal 
> messages.  :)
>
> Assuming you meant "without", I believe you are wrong.  At least in the US 
> you can leave it off and the message will get delivered... it takes much 
> longer, but it will get delivered.  Letters from my dear departed 
> Grandmother use to get through all the time, and she consistently used the 
> wrong postal code.
>
> Yes.  It has to be an absolute, otherwise you have a moving location which 
> I admit is wrong.  If RPID is using timezone with DST, then there would be 
> a difference between the two uses -- the RPID use would be for the 
> calculation of local time whereas this use would be for the specification 
> of location.
>
> -andy
>
>