Subject: [Geopriv] Timezones in Civic locations

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 27 Mar 2006 23:14:48 -0600

The issue was raised about the inclusion of timezone in the civic address format.I strongly suggest that this information is left out of the format for the following reasons:

*	A timezone is time-dependent, but the proposal was not to support things like daylight savings.  To me, that reduces the usefulness of the information.  If the 15 degree band of longitudes is important information, we have geodetic encodings for that information.
*	Timezone is not location information.  Timezone is one piece of data that can be derived from location information, but we need to be very clear about what is location data and what is derived from it.

Unless someone has a more convincing argument for their inclusion in the civic draft, I would like to propose that we progress the draft without this datum.

Cheers,
Martin.

------------------------------------------------------------------------------------------------
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: "Carl Reed OGC Account" <[email-masked]>
Date: Tue, 28 Mar 2006 08:25:17 -0700

I do not see any requirement for time zone. We never use time zone for any 
of our standards. Only time and we use the ISO standards for expressing 
time.

Carl

----- Original Message ----- 
From: "Thomson, Martin" <[email-masked]>
To: <[email-masked]>
Sent: Monday, March 27, 2006 10:14 PM
Subject: [Geopriv] Timezones in Civic locations

> The issue was raised about the inclusion of timezone in the civic address 
> format.I strongly suggest that this information is left out of the format 
> for the following reasons:
>
>
> * A timezone is time-dependent, but the proposal was not to support things 
> like daylight savings.  To me, that reduces the usefulness of the 
> information.  If the 15 degree band of longitudes is important 
> information, we have geodetic encodings for that information.
> * Timezone is not location information.  Timezone is one piece of data 
> that can be derived from location information, but we need to be very 
> clear about what is location data and what is derived from it.
>
> Unless someone has a more convincing argument for their inclusion in the 
> civic draft, I would like to propose that we progress the draft without 
> this datum.
>
> Cheers,
> Martin.
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 28 Mar 2006 10:43:23 -0500

As I noted during the meeting, the RPID (rich presence) information 
already includes time-offset information. During the discussion for that 
draft, it was said that the most useful aspect of timezone information 
is to avoid accidentally calling somebody when it is 2 am at that 
location. Providing time offset in presence is the most direct way to do 
that and avoids having to translate time zone information like 
Americas/New_York into what you actually care about. There are known 
problems during the transition to and from DST, but those events are 
rare enough and the error small enough that they didn't seem to matter 
for the applications that people had in mind.

In short, I also see no need for this information in GEOPRIV objects or 
data formats.

Henning

Carl Reed OGC Account wrote:
> I do not see any requirement for time zone. We never use time zone for 
> any of our standards. Only time and we use the ISO standards for 
> expressing time.
> 
> Carl
> 
> ----- Original Message ----- From: "Thomson, Martin" 
> <[email-masked]>
> To: <[email-masked]>
>> The issue was raised about the inclusion of timezone in the civic 
>> address format.I strongly suggest that this information is left out of 
>> the format for the following reasons:
>>
>>
>> * A timezone is time-dependent, but the proposal was not to support 
>> things like daylight savings.  To me, that reduces the usefulness of 
>> the information.  If the 15 degree band of longitudes is important 
>> Unless someone has a more convincing argument for their inclusion in 
>> the civic draft, I would like to propose that we progress the draft 
>> without this datum.
>>
>> Cheers,
>> Martin.
>>

---

From: Andrew Newton <[email-masked]>
Date: Thu, 30 Mar 2006 11:14:24 -0500

On Mar 28, 2006, at 12:14 AM, Thomson, Martin wrote:

> Unless someone has a more convincing argument for their inclusion  
> in the civic draft, I would like to propose that we progress the  
> draft without this datum.

A time zone is certainly a location, and excluding it from a location  
object because we most commonly use it to calculate local time does  
not make it any less a location.  If the threshold for inclusion of  
datums in a location object is "convincing argument", then I'm afraid  
there will have to be some other datums thrown out.

As to the other points in this thread:

*) PIDF-LO is used in more than just RPID, so such a thing could be  
relevant for non-RPID applications.

*) I don't see how GML is relevant here.  A time zone is a civic  
element.

If time zone can be represented independent of daylight savings,  
there should be no issue with including it in PIDF-LO.  Of course, if  
it cannot be represented of daylight savings, then I agree that it  
would cause more harm than good.

-andy

---

From: "Carl Reed OGC Account" <[email-masked]>
Date: Fri, 31 Mar 2006 16:19:43 -0700

Hi -

The OGC Members have also considered and continue to work various temporal 
aspects as related to location. Whether timezones are included as an 
optional element (or not) in civic addresses, a couple of notes:

GML date-time values may include standard ISO 8601 strings with time zone
offset (this is the default temporal reference system).

e.g., using the extended ISO-8601 format

<gml:TimeInstant>
  <gml:timePosition>2006-03-31T10:46-08:00</gml:timePosition>
<gml:TimeInstant>

AND some issues uncovered in the OGC work

.ISO 8601 does not specify a single character convention for time zones, 
requires using an offset to UTC
.
Standardize the use of time offset to represent time zones
-Therefore, does a service assume  20050101T100000Z = 20050101T100000 = 
20050101T100000-0000
-What to do when a service requests data at a particular offset?
Such as Filter on <time-attribute> = 20050101T100000-0500
.Which of the following time zones are the resulting times?
-UTC (Zulu)
-Offset: -0500
-Local time of server
.Typically this requires conversion between UTC and local time offset on any 
temporal queries or payloads.
The above issues were identified as part of a major interoperability project 
coordinated by Northrup Grumman called TAP.

----- Original Message ----- 
From: "Andrew Newton" <[email-masked]>
To: "Thomson, Martin" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, March 30, 2006 9:14 AM
Subject: Re: [Geopriv] Timezones in Civic locations

> object because we most commonly use it to calculate local time does  not 
> make it any less a location.  If the threshold for inclusion of  datums in 
> a location object is "convincing argument", then I'm afraid  there will 
> have to be some other datums thrown out.
>
> *) I don't see how GML is relevant here.  A time zone is a civic  element.
>
> If time zone can be represented independent of daylight savings,  there 
> should be no issue with including it in PIDF-LO.  Of course, if  it cannot 
> be represented of daylight savings, then I agree that it  would cause more 
> harm than good.
>
> -andy
>