Subject: [Tzdist] draft-ietf-tzdist-caldav-timezone-ref - timezone vs time zone

From: Tobias Conradi <[email-masked]>
Date: Sun, 21 Sep 2014 05:04:21 +0200

2014-08-13 Daniel at
http://www.ietf.org/mail-archive/web/tzdist/current/msg00014.html
wrote

"It has **already** been agreed with you to change "timezone" to "time
zone".  We got your point"

http://datatracker.ietf.org/doc/draft-ietf-tzdist-caldav-timezone-ref/?include_text=1

------------------
OLD
http://datatracker.ietf.org/doc/draft-ietf-tzdist-caldav-timezone-ref/

NEW
http://datatracker.ietf.org/doc/draft-ietf-tzdist-caldav-time-zone-ref/

OLD
5.1.  CALDAV:timezone-service-set
5.2.  CALDAV:calendar-timezone-id
6.2.  CALDAV:timezone-id XML Element

NEW
5.1. CALDAV:time-zone-service-set
5.2. CALDAV:calendar-time-zone-id
6.2.  CALDAV:time-zone-id XML Element

OLD
https://timezones.example.com

NEW
https://time-zone-s.example.com

Additionally indicating that one is not talking about plural.

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Jonathan Leffler <[email-masked]>
Date: Sat, 20 Sep 2014 22:07:41 -0700

The suggested URL change is not necessary; the '-s' part in `time-zone-s'
is meaningless and if the name should be amended, it should be to either '
time-zone.example.com' or 'time-zones.example.com', but I don't think the
hyphen(s) help in the understanding of the domain name.

I'm not convinced that the CALDAV names need to be changed, either — there
is a difference between 'time zone' in running text and timezone used as a
term of the technology.  Likewise with the document names.

On Sat, Sep 20, 2014 at 8:04 PM, Tobias Conradi <[email-masked]>
wrote:

> _______________________________________________
> Tzdist mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tzdist
>

-- 
Jonathan Leffler <[email-masked]>  #include <disclaimer.h>
Guardian of DBD::Informix - v2013.0521 - http://dbi.perl.org
"Blessed are we who can laugh at ourselves, for we shall never cease to be
amused."

---

From: Tobias Conradi <[email-masked]>
Date: Sun, 21 Sep 2014 07:53:28 +0200

On Sun, Sep 21, 2014 at 7:07 AM, Jonathan Leffler
<[email-masked]> wrote:

> there
> term of the technology.

The "term in technology" can run in text too and does so in any
English language documentation of the term.

But if you think there are two that are of concern for tzdist, please
amend the glossary.

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

On Sun, Sep 21, 2014 at 7:07 AM, Jonathan Leffler
<[email-masked]> wrote:
> The suggested URL change is not necessary; the '-s' part in `time-zone-s' is
> meaningless and if the name should be amended, it should be to either
> 'time-zone.example.com' or 'time-zones.example.com', but I don't think the

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Tobias Conradi <[email-masked]>
Date: Sun, 21 Sep 2014 07:58:04 +0200

On Sun, Sep 21, 2014 at 7:07 AM, Jonathan Leffler
<[email-masked]> wrote:
> meaningless
I thought it is a service name, if it would be removed, then it would
be the name of another service.

> and if the name should be amended, it should be to either
You seem to understand the "s" as a plural marker. This shows how the
hyphen(s) can help in "the understanding of the domain name".

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Lester Caine <[email-masked]>
Date: Sun, 21 Sep 2014 08:42:31 +0100

> 6.2.  CALDAV:time-zone-id XML Element

These can only be changed when the reference document is also changed!
http://www.ietf.org/rfc/rfc4791.txt defines these terms and the
VTIMEZONE packet. Until such time as this is rewriten, then any
REFERENCE to that must match the definitions contained there.

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

---

From: Tobias Conradi <[email-masked]>
Date: Sun, 21 Sep 2014 09:51:25 +0200

> These can only be changed when the reference document is also changed!
Let's check whether the "!" is justified.

> http://www.ietf.org/rfc/rfc4791.txt defines these terms
In which section(s)?

> and the
> VTIMEZONE packet.
I cannot find the string "packet" in http://www.ietf.org/rfc/rfc4791.txt .

> Until such time as this is rewriten, then any
Agreed. But I don't see any.

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Tobias Conradi <[email-masked]>
Date: Sun, 21 Sep 2014 09:52:56 +0200

On Sun, Sep 21, 2014 at 9:50 AM, Eliot Lear <[email-masked]> wrote:
> Tobias,
> Please slow down.
With what?

>  You're overloading the group again.
When did I "overload" the group before?

How do you define "overload"?

> Eliot

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Lester Caine <[email-masked]>
Date: Sun, 21 Sep 2014 09:28:02 +0100

> Agreed. But I don't see any.

A new word comes into use by it's common usage. That timezone has been
the usage in technical documentation such as these standards from a time
when we did not have nitpickers pulling apart the meaning of any word is
a simple fact. That there should have been a definition of the term in
earlier documents is obviously now an oversight that should have been
questioned at the time. That the term is enshrined in the published
document IS a fact and therefore ! is valid. Until such time as you can
convince people to rewrite every historic document then the term
timezone remains a valid technical term, and it can be defined as a
description of it's component parts. Some historic material such as that
used to compile timezone data may be of questionable provenance, but the
use of 'timezone' is a well documented fact. That THIS document should
correct an earlier mistake is acceptable, but I have yet to see any
reason to now remove the use of timezone as a single word to describe
the information we ARE now formally defining. So yes the mistake here is
not accepting that timezone does have acceptable provenance and blindly
rewriting historic documents just because someone objects to its common
usage !!!

---

From: Eliot Lear <[email-masked]>
Date: Sun, 21 Sep 2014 11:11:40 +0200

Hi,

First, I want to stress that timezone versus time zone is an editorial
change.  The working group should not spend time on this sort of thing,
and it is okay to go directly to the document authors on the matter.  If
you don't get satisfaction from them, then raise it back to the WG. 
This having been said, going down the list...

> http://datatracker.ietf.org/doc/draft-ietf-tzdist-caldav-timezone-ref/?include_text=1

This change should not be made.  The name of a draft is ephemeral.  That
draft name will not appear in the RFC when it is approved.  Furthermore,
any such change would impose a burden on the secretariat.
> 6.2.  CALDAV:time-zone-id XML Element

Before any of the above changes are made, I would want to know the
impact on any running code.  That should take precedent over any
editorial issue.
> https://time-zone-s.example.com

This is editorial.

Eliot

---

From: Lester Caine <[email-masked]>
Date: Sun, 21 Sep 2014 10:46:28 +0100

> This having been said, going down the list...

The latest list of corrections from Tobias have prompted me to think
about this again. and I now formally wish to raise an objection to this
'editorial change'.

That the term 'timezone' is now a fundamental element of many of the
underlying systems is a fact and none of those systems have any reason
to change their usage. That the term has NOT been formally defined in
the past is the mistake here and goes back to the late 90's? But it's
use is now embedded in both the iCalendar standard, and the common
languages such as PHP and Java. There is nothing wrong with use of
'timezone' in the CALDAV standard just as there is nothing wrong with
it's CURRENT use everywhere else. So we simply formalize the definition
of 'timezone' in this document and remove ALL the hassle of interfacing
with systems that have now been using that term for many years without
objections? We chan the ask to simply roll back the similar rewrite of
history on the tz database itself!

Not formally adopting the term is creating much more trouble than is
necessary and there is nothing actually incorrect. Even google
transparently intermixes the terms which simply adds to the confusion
when trying to check real world usage.

---

From: Lester Caine <[email-masked]>
Date: Sun, 21 Sep 2014 13:01:26 +0100

> about this again. and I now formally wish to raise an objection to this

Having now cut the grass and relaxed I can perhaps elaborate a little on
this. Tobais's nitpicking was what got my goat, and while I was happy to
let him have his way, the more I look at this the more that decision is
simply wrong.

I accept that 'Time Zone' is a more common designation with many usages
which is why I was happy to go along with that, but once one moves into
the world of software and code, that 'space' becomes a major roadblock
and has to be replaced. THAT is why traditionally it has simply been
dropped, and this is the norm when writing code. When producing function
names TimeZone... is another normal concatenation using CamelCase to
remove the space while leaving the 'sense'.

I was happy to live with the documentation retaining the space but I
find the drive to rework 15+ years of work which uses the concatenated
version exclusively a bridge too far. That is why I'd like to find out
if there is any support for formalizing the definition of 'timezone'
simply to eliminate any future confusion? At the very least I think a
proper acceptance that 'timezone' and 'TimeZone' both have a valid
existence and should not be needlessly reworked?

There are many more important things to sort out such as getting a
proper definition formally accepted. Does the XML standard STILL define
a 'Timezone' as - Timezones are durations with (integer-valued) hour and
minute properties ... No wonder the web system is so badly broken :(

---

From: Rob Seaman <[email-masked]>
Date: Sun, 21 Sep 2014 06:26:51 -0700

A larger issue with terminology would be having a single term mean two different things (violating univocity).  Having two different synonyms mean the same thing is commonplace.  I suspect many of us have noted that both variations of timezone and time zone are widely used and represent the same concept.

Kara Warburton of ISO Technical Committee 37 (Terminology) presented some excellent slides on univocity at a UTC/leapsecond (or is it leap second? ;-) session that should be broadly applicable to tz terminology as well:

	http://futureofutc.org/aas223/presentations/2-1-ISOterminologyAAS.pdf

My recommendation would be that any tzdist documents should explicitly state that both variations are in use, but that one or the other would be used by the authors except for cases in which both might be used explicitly.  Most of us likely don't have a huge preference either way other than wanting consistency in the documents.

As has been said, this is an editorial issue and risks being a distraction to the WG.

Rob Seaman
National Optical Astronomy Observatory
Tucson, AZ
--

---

From: Lester Caine <[email-masked]>
Date: Sun, 21 Sep 2014 15:18:58 +0100

> My recommendation would be that any tzdist documents should explicitly state that both variations are in use, but that one or the other would be used by the authors except for cases in which both m…
In the short term this is just a matter of the acceptance of a preferred
format for coded elements? The use of an '_' to replace the space is not
acceptable in some coding standards and the '-' has a similar objection.
Simply dropping the space is what has happened in all the languages I
work with, so accepting that fact while documenting with a space can be
an acceptable standard? Trying to get third parties to change their
current standards is not required? And similarly coding elements WITHIN
the standard can just as legitimately be timezone rather than insisting
on time-zone or time_zone?

> As has been said, this is an editorial issue and risks being a distraction to the WG.
That the third party users already have a standard should be recognised.
It has already been indicated that VTIMEZONE is not going to change and
<timezone> is already a widely used standard for XML data. What seems
more of a problem IS the use of 'timezone' to define a fixed offset from
UTC rather than a real tz dataset. Coupled with minute limited accuracy.
tzdist needs to define just what a time?zone is.

I've started gathering some related material here and would welcome any
input on other examples privately to keep this off the list ...
http://timedb.co.uk/wiki/view/Confusion+in+the+use+of+%27timezone%27

The leap?second problem is one I've managed to avoid by the simple
expedient that I don't use second based counts, but day and fraction of
day so the extra second does not matter :)

---

From: Tobias Conradi <[email-masked]>
Date: Sun, 21 Sep 2014 17:07:08 +0200

On Sun, Sep 21, 2014 at 11:11 AM, Eliot Lear <[email-masked]> wrote:
....
> This change should not be made.

It was promised by Daniel that it would:
http://www.ietf.org/mail-archive/web/tzdist/current/msg00014.html

It was a reply to an email that referred to
http://www.ietf.org/mail-archive/web/tzdist/current/msg00004.html

>  The name of a draft is ephemeral.
http://dictionary.reference.com/browse/ephemeral
"lasting a very short time"

Will all email archives be deleted? Will even private emails that
people have be changed or deleted? I suspect no.

Then I wonder how "very short time" is defined.

It breaks tools. I requested the change to be made _before_ adoption
as WG document.

Source:
http://www.ietf.org/mail-archive/web/tzdist/current/msg00016.html

You also contradict your own

"First, I want to stress that timezone versus time zone is an editorial
change.  The working group should not spend time on this sort of thing,
and it is okay to go directly to the document authors on the matter."

because you opposed this "editorial" change publicly.

> That
> draft name will not appear in the RFC when it is approved.
OK.

> Furthermore,
Now it is a burden to WG members that are left with a broken work flow.

> impact on any running code.  That should take precedent over any
People that implemented the unfinished specification can change their code?

>> https://time-zone-s.example.com
So, some of the occurrences are editorial (in your email the #3) and
some not (#1, #2). How can one predict which ones the chair Eliot Lear
considers one way or the other?

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Tobias Conradi <[email-masked]>
Date: Sun, 21 Sep 2014 17:25:14 +0200

On Sun, Sep 21, 2014 at 3:26 PM, Rob Seaman <[email-masked]> wrote:
> Having two different synonyms mean the same thing is commonplace.
commonplace != best practice

> I suspect many of us have noted that both variations of timezone and time zone are widely used and represent the same concept.

Where it represents the same concepts, it helps to use only one term.
More widely used is "time zone", that was the reason why I initially
proposed the change.

http://www.ietf.org/mail-archive/web/tzdist/current/msg00004.html
with reference to an email from 2014-07-03

timezone started in the late 1970s says
https://books.google.com/ngrams/graph?content=time+zone%2CTime+zone%2Ctimezone%2CTimezone%2CTimeZone%2Czone+time&year_start=1800&year_end=2000&corpus=15&smoothing=3&share=&direct_url=t1%3B%2Ctime%20zone%3B%2Cc0%3B.t1%3B%2CTime%20zone%3B%2Cc0%3B.t1%3B%2Ctimezone%3B%2Cc0%3B.t1%3B%2CTimezone%3B%2Cc0%3B.t1%3B%2CTimeZone%3B%2Cc0%3B.t1%3B%2Czone%20time%3B%2Cc0

and referer took off in the 1990s
https://books.google.com/ngrams/graph?content=referer%2Creferrer&year_start=1800&year_end=2000&corpus=15&smoothing=3&share=&direct_url=t1%3B%2Creferer%3B%2Cc0%3B.t1%3B%2Creferrer%3B%2Cc0

It is the choice of this WG to go a route similar to referer or one
similar to referrer.

>         http://futureofutc.org/aas223/presentations/2-1-ISOterminologyAAS.pdf
I currently have no PDF viewer.

> My recommendation would be that any tzdist documents should explicitly state that both variations are in use, but that one or the other would be used by the authors except for cases in which both m…

My recommendation is that in case a statement "that both variations
are in use" is made, it would not be made in "any tzdist documents"
but in one that defines "time zone". There is currently one that has a
glossary.

AFAICS that Glossary section is currently the best place to make such
a statement.

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Tobias Conradi <[email-masked]>
Date: Mon, 22 Sep 2014 16:31:59 +0200

Barry,

I think that after contacting a chair, the next level is the AD. I
think you are the AD. That's why I write to you.

I got no answer to my questions below.

Since I was already sanctioned without seeing what for, I suspect that
this is a new try to start quasi random sanctions against me.

I would either like answers, otherwise I would like sanctions against
Eliot Lear for disruption of my contributions to the TZDIST WG.

Tobias

---------- Forwarded message ----------
From: Tobias Conradi <[email-masked]>
Date: Sun, Sep 21, 2014 at 9:52 AM
Subject: Re: [Tzdist] draft-ietf-tzdist-caldav-timezone-ref - timezone
vs time zone
To: Eliot Lear <[email-masked]>, Time Zone Data Distribution Service
<[email-masked]>

With what?

--
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 22 Sep 2014 11:01:17 -0400

Hi Tobias,

> zone".  We got your point"

My position is as follows: the correct term for use in prose is "time 
zone". However, when used in protocol elements, such as WebDAV properties 
or names of XML or JSON tokens, I believe "timezone" is the best choice. I 
believe my position is backed up by existing precedent. Notably:

1) RFC 5545 uses "VTIMEZONE" not "VTIME-ZONE".
2) RFC 4791 uses the XML element CALDAV:calendar-timezone (yes I was a 
co-author on that spec so you can take this for what its worth).
3) RFC 4833 uses tokens OPTION_NEW_POSIX_TIMEZONE and 
OPTION_NEW_TZDB_TIMEZONE.
4) Unicode consortium: as per 
<http://userguide.icu-project.org/datetime/timezone> class names are 
"TimeZone" and "SimpleTimeZone". They use "time zone" in the prose.
5) Examples of URLs using "timezone": <http://www.worldtimezone.com>, 
<http://www.timezonecheck.com>, <http://www.timezoneconverter.com>, 
<http://24timezones.com>, <http://whatismytimezone.com> etc.
6) Java: <http://docs.oracle.com/javase/7/docs/api/java/util/TimeZone.html> 
similar to Unicode in its use of "TimeZone" for class names.
7) Windows: 
<http://technet.microsoft.com/en-us/library/cc749073(v=WS.10).aspx> and XML 
element <timezone>
8) PHP: <http://php.net/manual/en/datetime.gettimezone.php> has "Timezone" 
used in the name of a method.

To be fair, there are some counter examples, e.g., SQL uses "TIME ZONE". 
But for the most part, when "time zone" is used in the context of a 
protocol "token", it is most commonly seen as "timezone". Therefore, I 
would prefer to leave the spec as it is in that regard. If there is WG 
consensus to make a change, then of course I will do so.

-- 
Cyrus Daboo

---

From: Ken Murchison <[email-masked]>
Date: Mon, 22 Sep 2014 11:04:29 -0400

My preference is to leave it as "timezone" in protocol elements as is 
currently done in draft-ietf-tzdist-caldav-timezone-ref.

On 09/22/2014 11:01 AM, Cyrus Daboo wrote:
> zone". However, when used in protocol elements, such as WebDAV 
> properties or names of XML or JSON tokens, I believe "timezone" is the 
> best choice. I believe my position is backed up by existing precedent. 
> Notably:
>
> 6) Java: 
> <http://docs.oracle.com/javase/7/docs/api/java/util/TimeZone.html> 
> <http://technet.microsoft.com/en-us/library/cc749073(v=WS.10).aspx> 
> and XML element <timezone>
> 8) PHP: <http://php.net/manual/en/datetime.gettimezone.php> has 
> "Timezone" used in the name of a method.
>
> To be fair, there are some counter examples, e.g., SQL uses "TIME 
> ZONE". But for the most part, when "time zone" is used in the context 
> of a protocol "token", it is most commonly seen as "timezone". 
> Therefore, I would prefer to leave the spec as it is in that regard. 
> If there is WG consensus to make a change, then of course I will do so.
>
>

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

---

From: Tobias Conradi <[email-masked]>
Date: Mon, 22 Sep 2014 17:40:36 +0200

On Mon, Sep 22, 2014 at 5:01 PM, Cyrus Daboo <[email-masked]> wrote:
> My position is as follows: the correct term for use in prose is "time zone".
> However, when used in protocol elements, such as WebDAV properties or names
> of XML or JSON tokens, I believe "timezone" is the best choice. I believe my
> position is backed up by existing precedent.
Precedent that you created.

> 1) RFC 5545 uses "VTIMEZONE" not "VTIME-ZONE".
This is a component name. No component name contains a "-"

> co-author on that spec so you can take this for what its worth).
Not worth much.

> OPTION_NEW_TZDB_TIMEZONE.
Eggert and Lear messed it up.

> "TimeZone" and "SimpleTimeZone". They use "time zone" in the prose.
They use differences in case to indicate word boundaries.

> <http://24timezones.com>, <http://whatismytimezone.com> etc.
URLs are another world.

> similar to Unicode in its use of "TimeZone" for class names.
As in Unicode they use differences in case to indicate word boundaries.

> <http://technet.microsoft.com/en-us/library/cc749073(v=WS.10).aspx> and XML
No, it is <TimeZone>, XML is case-sensitive. As in Unicode they use
differences in case to indicate word boundaries.

> used in the name of a method.
They messed it up.

> To be fair, there are some counter examples, e.g., SQL uses "TIME ZONE".
Unicode, Java, Windows, SQL are all counter examples.

Only Eggert, Lear, Daboo, PHP, URLs are sources for "timezone" or
"TIMEZONE" in sets where word boundary indication is available and
used.

> But
> for the most part, when "time zone" is used in the context of a protocol
> "token", it is most commonly seen as "timezone".
Does not seem so.

> Therefore, I would prefer
> to leave the spec as it is in that regard.
I would prefer word boundary indication.

Source:

Which was a reply to
http://www.ietf.org/mail-archive/web/tzdist/current/msg00012.html

which argued
----------------------
>  if this is purely one person's preference over
> another's,
As presented in the proposal
http://www.ietf.org/mail-archive/web/tzdist/current/msg00004.html
it is not.
-----------------------

The proposal 2014-08-12
http://www.ietf.org/mail-archive/web/tzdist/current/msg00004.html
said:
I propose to change their names to
- draft-douglass-time-zone-service-11
- draft-daboo-caldav-time-zone-ref-01
and to replace in the text bodies "timezone" with "time zone"

That means the proposal was not only about changing English prose.

So, if the WG chair was saying the truth with "We got your point",
then this including changes to strings that are not English prose.

Some IETF RFCs and PHP don't indicate the word boundary where they
could have done. But I see no IETF rule that one has to go on with
repeating such practice.

Precedence:
https://wiki.whatwg.org/wiki/Meta_referrer
is not repeating the spelling mistake of HTTP referer.

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 22 Sep 2014 11:52:12 -0400

Hi Tobias,

>> a change, then of course I will do so.

I am afraid we are just going to disagree on this, so let's just go with 
working group consensus on this issue.

-- 
Cyrus Daboo

---

From: Dave Thewlis <[email-masked]>
Date: Mon, 22 Sep 2014 09:05:20 -0700

I agree with Ken.  There is no question of misunderstanding and  at least in practice “time zone” versus “timezone” seems to be a distinction without a difference.  

Dave Thewlis

On Sep 22, 2014, at 8:04 AM, Ken Murchison <[email-masked]> wrote:

> My preference is to leave it as "timezone" in protocol elements as is currently done in draft-ietf-tzdist-caldav-timezone-ref.
> 
> 
> 
>> --On September 21, 2014 at 5:04:21 AM +0200 Tobias Conradi <[email-masked]> wrote:
>> 
>> My position is as follows: the correct term for use in prose is "time zone". However, when used in protocol elements, such as WebDAV properties or names of XML or JSON tokens, I believe "timezone" is the best choice. I believe my position is backed up by existing precedent. Notably:
>> 
>> 2) RFC 4791 uses the XML element CALDAV:calendar-timezone (yes I was a co-author on that spec so you can take this for what its worth).
>> 3) RFC 4833 uses tokens OPTION_NEW_POSIX_TIMEZONE and OPTION_NEW_TZDB_TIMEZONE.
>> 4) Unicode consortium: as per <http://userguide.icu-project.org/datetime/timezone> class names are "TimeZone" and "SimpleTimeZone". They use "time zone" in the prose.
>> 5) Examples of URLs using "timezone": <http://www.worldtimezone.com>, <http://www.timezonecheck.com>, <http://www.timezoneconverter.com>, <http://24timezones.com>, <http://whatismytimezone.com> etc.
>> 6) Java: <http://docs.oracle.com/javase/7/docs/api/java/util/TimeZone.html> similar to Unicode in its use of "TimeZone" for class names.
>> 7) Windows: <http://technet.microsoft.com/en-us/library/cc749073(v=WS.10).aspx> and XML element <timezone>
>> 8) PHP: <http://php.net/manual/en/datetime.gettimezone.php> has "Timezone" used in the name of a method.
>> 
>> To be fair, there are some counter examples, e.g., SQL uses "TIME ZONE". But for the most part, when "time zone" is used in the context of a protocol "token", it is most commonly seen as "timezone". Therefore, I would prefer to leave the spec as it is in that regard. If there is WG consensus to make a change, then of course I will do so.
>> 
>> 
> 
> 
> -- 
> Kenneth Murchison

--
Dave Thewlis, Executive Director
CalConnect - The Calendaring and Scheduling Consortium
+1 707 840 9391 voice | +1 707 498 2238 mobile | +1 415 946 3454 fax
http://www.calconnect.org | [email-masked]

---

From: Gren Elliot <[email-masked]>
Date: Mon, 22 Sep 2014 17:07:48 +0100

I agree too.

Gren Elliot

Forwarded message:

> From: Dave Thewlis <[email-masked]>
> To: Murchison Ken <[email-masked]>
> Cc: [email-masked]
> Date: Monday, 22 September 2014 17:05:20
> Subject: Re: [Tzdist] draft-ietf-tzdist-caldav-timezone-ref - timezone vs time zone
>  
> On Sep 22, 2014, at 8:04 AM, Ken Murchison <[email-masked] (mailto:[email-masked])> wrote:
> > > --On September 21, 2014 at 5:04:21 AM +0200 Tobias Conradi <[email-masked] (mailto:[email-masked])> wrote:
> > >  
> > [email-masked] (mailto:[email-masked])
> http://www.calconnect.org | [email-masked] (mailto:[email-masked])
>  
>  
>  
> [email-masked] (mailto:[email-masked])

---

From: Lester Caine <[email-masked]>
Date: Mon, 22 Sep 2014 17:12:58 +0100

> working group consensus on this issue.

And for all the additional reasons I documented, I support the retaining
of space less designations where they already exist in the field and for
the matching fields in the protocol.

I will not be replacing any historic uses of timezone in my own material
and will continue to use that in these contexts as I do not accept there
is anything wrong with that anyway.

---

From: Tobias Conradi <[email-masked]>
Date: Mon, 22 Sep 2014 19:17:08 +0200

> currently done in draft-ietf-tzdist-caldav-timezone-ref.
Is stating a personal preference for one choice without providing
reasoning, whilst other parties provided reasoning, a valid way when
working on IETF specifications?

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Tobias Conradi <[email-masked]>
Date: Mon, 22 Sep 2014 19:20:06 +0200

On Mon, Sep 22, 2014 at 5:52 PM, Cyrus Daboo <[email-masked]> wrote:
> I am afraid we are just going to disagree on this,
You provided reasons for your point of view. I showed where your
reasoning failed. It would now be straight forward to show where mine
failed or to agree with me.

>so let's just go with
Then go and change.

WG chair Daniel made a pretty clear statement.

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Eliot Lear <[email-masked]>
Date: Mon, 22 Sep 2014 19:21:48 +0200

Can we all please pause on this issue?  We are going round and round. 
Cyrus agreed to make a number of changes.  Let's see how they come out
in the next draft.  Tobias, if at that point you still have concerns,
FIRST raise them directly with Cyrus.  If you disagree with his
conclusion, THEN BRIEFLY raise them again on this list.

Thanks,

Eliot

---

From: Tobias Conradi <[email-masked]>
Date: Mon, 22 Sep 2014 19:24:47 +0200

On Mon, Sep 22, 2014 at 6:05 PM, Dave Thewlis
<[email-masked]> wrote:
> I agree with Ken.
Who only gave a "my preference"-statement without any reasoning.

> There is no question of misunderstanding
It has been shown that omissions of word boundaries can lead to
different understandings, "timezones" has been interpreted as "time
zones" and as "time zone 'secure'"

> and at least in
> practice “time zone” versus “timezone” seems to be a distinction without a
> difference.
The decision was to use the two word version.

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com