Subject: RE: [Geopriv] Timezones in Civic locations

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 6 Apr 2006 17:14:26 -0500

Doesn't this all come down to what you want to use the information for?

The civic address format currently has two uses, as far as I can tell:

 - jurisdictional civic - how can someone find the person, given sufficient knowledge of the civic designations (person to person)

 - postal civic - how can I get a message to the person, probably via a postman (message to person)

The two are very commonly intertwined; indeed, the two are often the same.  Hence it makes some sense to combine them in a single format.  DHCP civic includes a section on distinguishing between the two.

(Side Note: The two forms have very different usage models.  Most of our discussion relating to L7 and emergency use relates to jurisdictional civic.)

I think that Henning is suggesting that we need a statement of benefit to either use case before including the information.

> -----Original Message-----
> From: Andrew Newton [mailto:[email-masked]]
> Sent: Thursday, 6 April 2006 10:19 PM
> To: Henning Schulzrinne
> Cc: GEOPRIV
> Subject: Re: [Geopriv] Timezones in Civic locations
> 
> Henning, my comments in-line:
> 
> Henning Schulzrinne wrote:
> > This discussion echoes some of the SIMPLE discussion as to what to
> > include in the various enhanced presence documents. In many cases, it
> > seemed hard to say no for the specific reason that it would break
> > something or not work in some other way, but rather that there is a
> > fuzzy line of not making specifications or documents more complex than
> > needed, given the almost infinite number of pieces of status-related or
> > location-related information that could be included. I guess this is
> > somewhat of a slippery-slope argument, where zoning status and mean
> > annual temperature are waiting a few steps behind on the ski slope...
> 
> I think your examples for the slippery slope are off base.  Zoning
> status and mean annual temperature maybe attributes of locations, but
> they themselves are not locations.  Both a suburb in New Jersey and a
> suburb in Hawaii may be zoned 'Residential' but they are not the same
> location.  Both Montana and North Dakota may have the same mean annual
> temperature, but they are not the same location (despite contemporary
> thoughts to the contrary).
> 
> However, if you do have some rule of thumb that could be used to limit
> the bounds of the civic location schema that would be just as good as a
> good argument specifically against timezone (assuming the rule applies
> to timezone).
> 
> > I suspect such decisions are by their nature somewhat arbitrary,
> > particularly if there is no directly articulated customer demand.
> >
> > Thus, I think the question cannot be as to why something cannot be
> > included, but rather whether this is crucial to the current mission
> > scope and why it must be included to satisfy those needs.
> 
> We could certainly apply this to other elements for civic location under
> consideration.  I, for one, have no use for POBOX.  A POBOX is not part
> of an address that can be routed to for emergency services, and it is
> likely not the address of a target device such as a mobile phone or
> computer so it is unlikely to be used in presence either.
> 
> 
> > For example, the time offset in RPID was included since the core goal of
> > presence is to facilitate picking appropriate times and means for
> > communications and it was felt that preventing inadvertent phone calls
> > at 2am was furthering that goal.
> 
> I should note that as this working group spins up work on the l7
> location configuration protocol, that this is exactly an example of an
> application that may very well use the civicLOC schema outside of any
> presence architecture.
> 
> -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: Henning Schulzrinne <[email-masked]>
Date: Thu, 06 Apr 2006 18:31:57 -0400

That's a good distinction; another one might be primary vs. derived. The 
current civic data is all primary information, in other words, it is 
necessary to describe location unambiguously for either person-to-person 
to message-to-person applications. (There are some minor exceptions 
where in some cases, certain elements can be omitted since a lower-layer 
names happens to be unique across a larger area ["Divorce Ct, PA"], but 
those are exceptions.)

Other suggested pieces of location-related information can be derived 
from this primary location information, be it the timezone, census tract 
or the zoning status. For derived information, I think the bar for 
inclusion is higher. Postal codes, for example, could be considered 
derived information, but there sufficiently many exceptions 
(organizations, such as the IRS, with their own zip codes, etc.) that 
practicality argues for including them. All of these derived properties 
share this same basic feature, whether all places with the same value 
are in one contiguous area (as is mostly, but not completely, true for 
timezones) or not (as would be true for mean temperatures).

Thomson, Martin wrote:
> ------------------------------------------------------------------------
>

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 7 Apr 2006 07:44:46 -0400

Couple of points on this, not sure how relevant to a timezone discussion:
These two use cases are ALWAYS the same location (you can have more
specificity than the postal case can use).

The reason they are combined is because they are the same, but the different
purposes historically and institutionally evolved so that the representation
is slightly different, and because these are government functions there is
insufficient institutional inertia to change so that they use the same
representation. 

I think the "usage model" is not very different within the domain of the
protocol.  I usually think of this as there are components of the data
structure that are common use, and components that are for use only by
postal or only by jurisdictional, but many uses that want both.  As an
example of "both", consider a geocoder.  Good ones make use of all sorts of
information sources and their accuracy improves when more information is
known.   Finding my house is difficult because it is in Pine Township,
Allegheny County, Mars post office, zip 16046, when there is a Mars township
a couple miles away, but in Butler County, and about 15 Pine Townships in
Pennsylvania.  There is only one Pine Township that has a portion covered by
the 16046 Zip.  

The emergency case can usefully use both.  Clearly the dispatch of
responders, and all of the current databases are strictly jurisdictional,
but people often respond with postal when prompted for where they are and
having both available to the call taker will reduce confusion.

I don't think we are discussing justifying both jurisdictional community
name and postal community name, and I don't think there is a point in
discussing postal vs jurisdictional in any other context; certainly not in a
timezone discussion.

Brian

-----Original Message-----
From: Thomson, Martin [mailto:[email-masked]] 
Sent: Thursday, April 06, 2006 6:14 PM
To: Andrew Newton; Henning Schulzrinne
Cc: GEOPRIV
Subject: RE: [Geopriv] Timezones in Civic locations

 - jurisdictional civic - how can someone find the person, given sufficient
knowledge of the civic designations (person to person)

 - postal civic - how can I get a message to the person, probably via a
postman (message to person)

The two are very commonly intertwined; indeed, the two are often the same.
Hence it makes some sense to combine them in a single format.  DHCP civic
includes a section on distinguishing between the two.

(Side Note: The two forms have very different usage models.  Most of our
discussion relating to L7 and emergency use relates to jurisdictional
civic.)

I think that Henning is suggesting that we need a statement of benefit to
either use case before including the information.

> application that may very well use the civicLOC schema outside of any

----------------------------------------------------------------------------
--------------------
----------------------------------------------------------------------------
--------------------
[mf2]

---

From: Andrew Newton <[email-masked]>
Date: Fri, 07 Apr 2006 16:07:10 -0400

> timezones) or not (as would be true for mean temperatures).

Exactly how are timezones derived?  That has been asserted several times 
in this thread, but nobody has answered the question.

> The two are very commonly intertwined; indeed, the two are often the same.  Hence it makes some sense to combine them in a single format.  DHCP civic includes a section on distinguishing between th…

The reason DHCP Civic draws a distinction between these two use cases is 
that they're components are often interwined for these use cases and 
there was a desire to avoid confusion.  It was never meant to be to the 
exclusion of other use cases.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 7 Apr 2006 16:40:32 -0400

It's derived from location.  They start as longitude lines, spaced 15
degrees apart (360/24) but deviate from "ideal" almost always aligning with
some kind of jurisdictional boundary (like a country, state, county or
city).  There are some variations, so it is claimed there are actually 35
time zones.  I found this nice quote about U.S. Time Zones:

Time Zones, and their boundary lines, are established by Federal statute.
While most of the time zone division lines fall on county boundaries, a
number do not... the exceptions fall along township and section boundaries
as defined by the Public Land Survey System. It is also true that the
beginning and ending dates for the observance of Daylight Savings Time are
standardly established by statute... but certain states and certain counties
decline to observe Daylight Savings Time.

Brian

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: Friday, April 07, 2006 4:07 PM
To: Henning Schulzrinne
Cc: GEOPRIV; Thomson, Martin
Subject: Re: [Geopriv] Timezones in Civic locations

Thomson, Martin wrote:
>  - jurisdictional civic - how can someone find the person, given
sufficient knowledge of the civic designations (person to person)

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 07 Apr 2006 16:42:14 -0400

> in this thread, but nobody has answered the question.

Since timezones generally either follow jurisdictional or longitude 
lines, the mapping would follow two algorithms, depending on whether 
civic location information is available:

- If there is civic information, map the country, state and county to 
timezone. As noted earlier, this could be done in LoST, using the same 
basic mapping mechanism used for PSAP regions. The idea is very much the 
same, just the regions are somewhat larger. As far as I know, almost all 
such divisions are on a county basis (see 
http://www.statoids.com/tus.html), but that doesn't really matter. 
Apparently, Nebraska and North Dakota do this on a sub-county level, 
just to be interesting. ("Sioux county west of ND route 31")

- If you have only geo information, maintain polygons with the 
boundaries of the timezones. In the US, this would be mostly the county 
border database, which is publicly available and which we have used for 
a mock PSAP mapping. Again, almost exactly the same problem as finding 
the PSAP based on long/lat.

Given the oddities of sub-county timezone boundaries in the western US, 
one would presumably have to geocode and then map.

Time permitting, I plan to draft a 'urn:service:timezone' registration, 
if only as an illustration of what else mapping protocols could do.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 07 Apr 2006 16:44:33 -0400

For amusement on a Friday afternoon, consider the text below (from 
http://www.statoids.com/tus.html):

# 2006-04-02 02:00: The entire state of Indiana begins to observe DST. 
Also, six western counties (Daviess, Dubois, Knox, Perry, Pike, and 
Starke) move from ET to CT. Previously, all but fifteen counties had 
remained on Eastern Standard Time throughout the year. The fifteen 
exceptions included five southeastern counties (Clark, Dearborn, Floyd, 
Harrison, and Ohio), which were on ET with DST, and ten western counties 
(Gibson, Jasper, Lake, La Porte, Newton, Porter, Posey, Spencer, 
Vanderburgh, and Warrick), which were on CT with DST.

# Note: The DoT Final Rule gives the time of this change as 2:00 EST. At 
1:30 EST on that date, Indiana would have 82 counties on EST and ten 
counties on CST. The time in those ten counties would be 0:30 CST. At 
2:00 EST, the time in 74 of the eastern counties would jump forward to 
3:00 EDT. At the same moment, the other eight counties would switch from 
ET to CT, meaning that their time would change from 2:00 EST to 1:00 
CST. An hour later, all of the Central Time Zone, including now eighteen 
western Indiana counties, would jump ahead to 3:00 CDT. In short, the 
eight counties being switched to a new time zone would see their legal 
time change from 2:00 a.m. to 1:00 a.m., and an hour later from 2:00 
a.m. to 3:00 a.m. No one really expects the residents to make two 
changes that cancel each other out in the middle of the night. The DoT 
has been asked to rewrite its rule in a more realistic way.

Somebody from Indiana might be able to tell us whether they spend the 
night re-adjusting their clocks...

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 7 Apr 2006 17:05:20 -0400

yep

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: Friday, April 07, 2006 4:55 PM
To: [email-masked]
Cc: 'Henning Schulzrinne'; 'GEOPRIV'; 'Thomson, Martin'
Subject: Re: [Geopriv] Timezones in Civic locations

> decline to observe Daylight Savings Time.

In other words, they are just like postal codes... the boundaries are 
set based on a policy body.

-andy

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 7 Apr 2006 17:06:41 -0400

Rumors have it there were several very amusing hearings by the DOT in the
various Indiana counties that petitioned to change timezones.  Some counties
asked to change simply because their neighboring county also petitioned.  It
turns out the later county didn't make the change and the former did.  Now
the former wants to change back!  I believe technically Indiana
(Indianapolis is approx. center of the state with a longitude of -86
degrees) should be completely in the Central Time Zone (-90 +/- 7.5).  I
think I remember back in the Nixon-energy-crunch era is when Indiana made a
change to EST from CST.  The resistance to daylight savings time stems from
that change way back. 

The real driving force is the communities of interest.  Northwest Indiana
wants Chicago time whereas southeast Indiana wants Cincinnati time.
Obviously, the people in the middle don't have a very strong opinion!

-Marc-

> From: Henning Schulzrinne [mailto:[email-masked]] 
> Sent: Friday, April 07, 2006 4:45 PM
> To: [email-masked]
> Cc: 'GEOPRIV'
> Starke) move from ET to CT. Previously, all but fifteen 
> counties had remained on Eastern Standard Time throughout the 
> year. The fifteen exceptions included five southeastern 
> counties (Clark, Dearborn, Floyd, Harrison, and Ohio), which 
> were on ET with DST, and ten western counties (Gibson, 
> Jasper, Lake, La Porte, Newton, Porter, Posey, Spencer, 
> # Note: The DoT Final Rule gives the time of this change as 
> 2:00 EST. At 1:30 EST on that date, Indiana would have 82 
> counties on EST and ten counties on CST. The time in those 
> ten counties would be 0:30 CST. At 2:00 EST, the time in 74 
> of the eastern counties would jump forward to 3:00 EDT. At 
> the same moment, the other eight counties would switch from 
> ET to CT, meaning that their time would change from 2:00 EST 
> to 1:00 CST. An hour later, all of the Central Time Zone, 
> including now eighteen western Indiana counties, would jump 
> ahead to 3:00 CDT. In short, the eight counties being 
> switched to a new time zone would see their legal time change 
> from 2:00 a.m. to 1:00 a.m., and an hour later from 2:00 a.m. 
> to 3:00 a.m. No one really expects the residents to make two 
> changes that cancel each other out in the middle of the 
> night. The DoT has been asked to rewrite its rule in a more 
> realistic way.
> 
> 
> Somebody from Indiana might be able to tell us whether they 
> spend the night re-adjusting their clocks...
> 
> Brian Rosen wrote:
> > degrees apart (360/24) but deviate from "ideal" almost 
> always aligning 
> > with some kind of jurisdictional boundary (like a country, state, 
> > county or city).  There are some variations, so it is claimed there 
> > are actually 35 time zones.  I found this nice quote about 
> U.S. Time Zones:
> > 
> > While most of the time zone division lines fall on county 
> boundaries, 
> > a number do not... the exceptions fall along township and section 
> > boundaries as defined by the Public Land Survey System. It is also 
> > true that the beginning and ending dates for the observance of 
> > Daylight Savings Time are standardly established by statute... but 
> > certain states and certain counties decline to observe 
> Daylight Savings Time.
> > 
> > Brian
> > 
> > 
> >> from this primary location information, be it the timezone, census 
> >> tract or the zoning status. For derived information, I 
> think the bar 
> >> for inclusion is higher. Postal codes, for example, could be 
> >> considered derived information, but there sufficiently many 
> >> exceptions (organizations, such as the IRS, with their own 
> zip codes, 
> >> etc.) that practicality argues for including them. All of these 
> >> derived properties share this same basic feature, whether 
> all places 
> >> with the same value are in one contiguous area (as is 
> mostly, but not 
> >> completely, true for
> > Exactly how are timezones derived?  That has been asserted several 
> > times in this thread, but nobody has answered the question.
> > 
> > Thomson, Martin wrote:
> >>  - postal civic - how can I get a message to the person, 
> probably via 
> >> a
> > Hence it makes some sense to combine them in a single format.  DHCP 
> > civic includes a section on distinguishing between the two.
> > 
> > The reason DHCP Civic draws a distinction between these two 
> use cases 
> > is that they're components are often interwined for these use cases 
> > and there was a desire to avoid confusion.  It was never 
> meant to be 
> > to the exclusion of other use cases.
> > 
> > -andy
> > 
> >

---

From: Andrew Newton <[email-masked]>
Date: Fri, 07 Apr 2006 16:54:34 -0400

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 07 Apr 2006 17:23:24 -0400

> set based on a policy body.

Not quite. Postal codes often contain additional information that is not 
otherwise visible in the address. For example, our departmental postal 
code is 10027-7003. Try typing in "Columbia University", and you'll get 
a whole bunch of zip+4-code responses, all different.

As Wikipedia says (http://en.wikipedia.org/wiki/ZIP_Code)

"A ZIP+4 code uses the basic 5-digit ZIP plus an additional 4-digits to 
identify a geographic segment within the 5-digit delivery area, such as 
a city block, a group of apartments, an individual high-volume receiver 
of mail, or any other unit that could use an extra identifier to aid in 
efficient mail sorting and delivery."

In other words, unlike timezones, a single street address may have 
multiple 9-digit zip codes.

"In 1964, at the height of his popularity, Smokey Bear, mascot of the 
United States Forest Service, received so much fan mail that he was 
assigned his own ZIP code, 20252."

Henning

---

From: Andrew Newton <[email-masked]>
Date: Fri, 07 Apr 2006 18:08:57 -0400

> assigned his own ZIP code, 20252."

But both are still determined via a political process.  They are not 
derived -- meaning you cannot take the other components of the civic 
location alone and determine the timezone or the postal code.  Sure, 
there maybe a database somewhere that might be able to the mapping for 
some locations, but that is true of every aspect of a civic location 
with regards to geographical coordinates.  Otherwise, all of civic could 
be nixed under your guidelines thanks to geocoding... and I'm pretty 
sure that won't fly.

Now, I will ask this question for the 3rd time.  And perhaps somebody 
can answer it this time. Just what harm would it cause to include this 
datum?

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 07 Apr 2006 18:24:59 -0400

Andrew,

I'll try one more time to be succinct, but won't belabor the topic 
beyond this since you seem to just repeat the same "why not" argument.

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

(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."

Having a separate discussion on XML objects for location-derived 
information might be a useful thing, but as a completely separate 
namespace and independent of civic or geo coordinates. However, that 
seems a more appropriate discussion for a GIS-related standardization body.

Henning

> But both are still determined via a political process.  They are not 

Right - so are street names and county borders. That similarity tells us 
very little.

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

---

From: Andrew Newton <[email-masked]>
Date: Fri, 07 Apr 2006 19:21:48 -0400

> information as well since it has exactly the same properties.

The same is true of postal code.  Should we take it out?

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

> insufficient for zip codes.

There are more than just a handful of odd cases and therefore straight 
algorithmic conversion is not possible.

-andy

---

From: Randall Gellens <[email-masked]>
Date: Tue, 11 Apr 2006 14:39:00 -0700

At 4:40 PM -0400 4/7/06, Brian Rosen wrote:

>  It is also true that the

Just to be unbearably pedantic, my understanding has been that the 
term is "Daylight Saving Time" (with "saving" instead of "savings"). 
Wikipedia says the "savings" form does appear in at least one 
dictionary, though, but is still considered non-normative: 
<http://en.wikipedia.org/wiki/Daylight_saving_time>.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Two things are infinite: the universe and human stupidity;
and I'm not even sure about the universe.
                                        --Albert Einstein