Subject: RE: [Geopriv] Timezones in Civic locations

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 30 Mar 2006 11:32:46 -0600

You haven't addressed the primary concern, which is that timezone is a consequence of location, not a location datum.  This is about drawing a line.  There are many types of data that can be derived from location in this manner: the local language(s), what side of the road you drive on, the offset of magnetic north, the form of government, universal adult suffrage, the height of the water table...I could go on.
 
Incidentally, timezone is represented independently of daylight savings.  For instance, Australia/NSW, Canada/Eastern, Etc/GMT+10 [1].
[1] http://www.timezoneconverter.com/cgi-bin/tzref.tzc

________________________________

From: Andrew Newton [mailto:[email-masked]]
Sent: Fri 3/31/2006 2:14 AM
To: Thomson, Martin
Cc: [email-masked]
Subject: Re: [Geopriv] Timezones in Civic locations

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

------------------------------------------------------------------------------------------------
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: Thu, 30 Mar 2006 13:44:00 -0500

On Mar 30, 2006, at 12:32 PM, Thomson, Martin wrote:

> You haven't addressed the primary concern, which is that timezone  
> is a consequence of location, not a location datum.  This is about  
> drawing a line.  There are many types of data that can be derived  
> from location in this manner: the local language(s), what side of  
> the road you drive on, the offset of magnetic north, the form of  
> government, universal adult suffrage, the height of the water  
> table...I could go on.

Timezone is as much a consequence of location as country and postal  
code are a consequence of location.  Both are  arbitrarily specified  
by humans.

Local time in relation to UTC is a consequence of location, but  
timezones themselves are determined by humans.  If timezones actually  
followed longitudinal lines, I'd believe your argument, but anybody  
who has ever looked at a map of timezones for 2 seconds will tell you  
they are determined based on politics just like country borders.

And if we are to discount datums because they can be derived from  
other datums, then ZIP+4 should eliminate street number, street name,  
city, county, and state from PIDF-LO.

And your analogy on derivation is wrong. I'd like to see you derive  
the "local language" of 100 random people from either Quebec or  
southern Louisiana.  Chances are you will get it wrong a significant  
number of times.

> Incidentally, timezone is represented independently of daylight  
> savings.  For instance, Australia/NSW, Canada/Eastern, Etc/GMT+10 [1].

Well then, what's the big deal?

-andy

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 30 Mar 2006 15:06:07 -0500

> On Mar 30, 2006, at 12:32 PM, Thomson, Martin wrote:
...
> 
> And your analogy on derivation is wrong. I'd like to see you derive the 
> "local language" of 100 random people from either Quebec or southern 
> Louisiana.  Chances are you will get it wrong a significant number of 
> times.
> 
[PTT] You look at their >>first<< names. (-:

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 30 Mar 2006 16:16:00 -0500

So, is the current timezone draft moving it's way through the dhc wg
considered LCI and subject to RFC3693?

http://www.ietf.org/internet-drafts/draft-lear-dhc-timezone-option-02.txt

-Marc- 

> -----Original Message-----
> Sent: Thursday, March 30, 2006 1:44 PM
> To: Thomson, Martin
> Cc: [email-masked]
> > You haven't addressed the primary concern, which is that 
> timezone is a 
> > consequence of location, not a location datum.  This is 
> about drawing 
> > a line.  There are many types of data that can be derived from 
> > location in this manner: the local language(s), what side 
> of the road 
> > you drive on, the offset of magnetic north, the form of government, 
> > universal adult suffrage, the height of the water table...I 
> could go 
> > on.
> 
> Timezone is as much a consequence of location as country and 
> postal code are a consequence of location.  Both are  
> arbitrarily specified by humans.
> 
> Local time in relation to UTC is a consequence of location, 
> but timezones themselves are determined by humans.  If 
> timezones actually followed longitudinal lines, I'd believe 
> your argument, but anybody who has ever looked at a map of 
> timezones for 2 seconds will tell you they are determined 
> based on politics just like country borders.
> 
> And if we are to discount datums because they can be derived 
> from other datums, then ZIP+4 should eliminate street number, 
> street name, city, county, and state from PIDF-LO.
> 
> And your analogy on derivation is wrong. I'd like to see you 
> derive the "local language" of 100 random people from either 
> Quebec or southern Louisiana.  Chances are you will get it 
> wrong a significant number of times.
>

---

From: John Schnizlein <[email-masked]>
Date: Thu, 30 Mar 2006 16:49:14 -0500

And what about option 2 from RFC 2132?  These offsets are derived from  
location, in approximately 15 degree segments, subject to local  
political discretion?  Is this option to be retroactively subsumed  
under GeoPriv's scope?

3.4. Time Offset

    The time offset field specifies the offset of the client's subnet in
    seconds from Coordinated Universal Time (UTC).  The offset is
    expressed as a two's complement 32-bit integer.  A positive offset
    indicates a location east of the zero meridian and a negative offset
    indicates a location west of the zero meridian.

    The code for the time offset option is 2, and its length is 4 octets.

John

---

From: Andrew Newton <[email-masked]>
Date: Thu, 30 Mar 2006 18:57:29 -0500

Even if it was, aren't we talking about LO here?

-andy