Subject: Re: What day is 2010-01-02

From: "Phillips, Addison" <[email-masked]>
Date: Sat, 13 Mar 2010 15:21:29 -0500

(from digest)

> 
> ISO not withstanding, its still confusing if only because other
> cultures use yyddmm.  If the IETF website used something like  ISO-2010-01-02
> maybe.

Actually, for culturally-formatted date strings, cultures that prefer day-month order typically put the year at the trailing end. It turns out that cultures that put the year first in their local date format always use month-day order afterwards.

Unicode's Common Locale Data Repository (CLDR) project lists several hundred locales, which you can browse for both the sheer diversity of forms (separators, abbreviations, calendars, and such) within the relative homogeneity of overall patterns (just three: mdy, dmy, and ymd). See:

   http://www.unicode.org/cldr 

> 
> This format is less confusing:  02jan2010
> 

There are several benefits to using ISO 8601 (well, actually RFC 3339) which have already been reported on this thread, so I won't bludgeon the topic further. However, for those interested some useful links appear on here:

   http://www.w3.org/QA/Tips/iso-date
   http://www.w3.org/International/questions/qa-date-format 

Regards,

Addison

Addison Phillips
Chair -- W3C Internationalization WG

Internationalization is not a feature.
It is an architecture.

---

From: "Phillips, Addison" <[email-masked]>
Date: Sat, 13 Mar 2010 16:09:31 -0800

John Klensin noted:
> 
> While it doesn't change the conclusion, I've actually see many
> uses of ydm in the wild.  I haven't taken the time to try to
> find out, but I've assumed that was the reason why the current
> version of ISO 8601 moved to "one delimiter and it is hyphen"
> from the permissiveness about delimiter choices in its
> predecessors.
> 

Normally I hesitate before making sweeping statements like that :-). In this case, I omitted, for the sake of brevity, noting that there are many MANY formats in use, especially in specialized fields such as accounting, and that, like most anything involving culture or language, one can find nearly any variation, no matter how "strange" or "foreign" it seems to outsiders, that is actually in customary use *somewhere*. 

There is also a difference between "regularized" usage and formats derived by well-meaning people based on their own experience (i.e. a European might very well think first of ydm, being used to seeing the day preceding the month).

However, I'm unaware of any locale where 'ydm' is a *preferred* format, any casual or specialized usage notwithstanding. Probably someone will go find one, just to prove my first paragraph. In I18N, we usually say that the answer to any question begins with the phrase "well, it depends..."

Finally, if one is reading standards, it behooves one to understand the customs and language adopted there. Date formats such as this are one such example, just as certain English words have special meaning in a standards context. The use of a well-known, unambiguous format, such as ISO 8601-derived dates, is sensible as such a standard as it is generally inoffensive, language/culture neutral, and recognizable.

Addison

Addison Phillips

---

From: "Phillips, Addison" <[email-masked]>
Date: Sat, 13 Mar 2010 19:57:37 -0500

John Klensin noted:
> 
> ...  It was only the sweeping
> statement to which I was taking exception.  

Sweeping generalizations in regard to language or culture are always wrong.

~Addison

---

From: John C Klensin <[email-masked]>
Date: Sat, 13 Mar 2010 18:35:30 -0500

--On Saturday, March 13, 2010 15:21 -0500 "Phillips, Addison"
<[email-masked]> wrote:

> (from digest)
> 
>> 
>> ISO not withstanding, its still confusing if only because
>> other cultures use yyddmm.  If the IETF website used
>> something like  ISO-2010-01-02 maybe.
> 
> Actually, for culturally-formatted date strings, cultures that
> prefer day-month order typically put the year at the trailing
> end. It turns out that cultures that put the year first in
> their local date format always use month-day order afterwards.
> 
> Unicode's Common Locale Data Repository (CLDR) project lists
> several hundred locales, which you can browse for both the
> sheer diversity of forms (separators, abbreviations,
> calendars, and such) within the relative homogeneity of
> overall patterns (just three: mdy, dmy, and ymd). See:
> 

Addison,

    john

---

From: John C Klensin <[email-masked]>
Date: Sat, 13 Mar 2010 19:38:51 -0500

As expected, I completely agree.  It was only the sweeping
statement to which I was taking exception.  I'm certainly not
aware of anyplace where ydm is the officially-preferred format
although, like you, I wouldn't be especially surprised if
someone found one.

    john

--On Saturday, March 13, 2010 16:09 -0800 "Phillips, Addison"
<[email-masked]> wrote:

> Normally I hesitate before making sweeping statements like
> that :-). In this case, I omitted, for the sake of brevity,
> noting that there are many MANY formats in use, especially in
> specialized fields such as accounting, and that, like most
> anything involving culture or language, one can find nearly
> any variation, no matter how "strange" or "foreign" it seems
> to outsiders, that is actually in customary use *somewhere*. 
> 
> There is also a difference between "regularized" usage and
> formats derived by well-meaning people based on their own
> experience (i.e. a European might very well think first of
> ydm, being used to seeing the day preceding the month).
> 
> However, I'm unaware of any locale where 'ydm' is a
> *preferred* format, any casual or specialized usage
> notwithstanding. Probably someone will go find one, just to
> prove my first paragraph. In I18N, we usually say that the
> answer to any question begins with the phrase "well, it
> depends..."
> 
> Finally, if one is reading standards, it behooves one to
> understand the customs and language adopted there. Date
> formats such as this are one such example, just as certain
> English words have special meaning in a standards context. The
> use of a well-known, unambiguous format, such as ISO
> 8601-derived dates, is sensible as such a standard as it is
> generally inoffensive, language/culture neutral, and
> recognizable.
> 
> Addison
> 
> Addison Phillips

---

From: todd glassey <[email-masked]>
Date: Mon, 15 Mar 2010 09:13:31 -0700

> <[email-masked]> wrote:

This is a prime example of the IETF's waste of time and energy. The ISO
8601 date standard is the obvious answer and yet this convo is still
going...

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 17 Mar 2010 14:11:30 +0100

> There is also a difference between "regularized" usage and formats derived by well-meaning people based on their own experience (i.e. a European might very well think first of ydm, being used to se…

No way.

Year-month-day makes sense because it matches the way we parse numbers. Day-month-year makes sense because that's the usual way to write it down. All other ways to do it, including using only two digits for the year, are confusing, ambiguous or both. For instance, even if I know that 4/7 is supposed to be the seventh of april it confuses me, and often you don't know so it's also ambiguous.

I know that some people feel it's important to make the IETF website easier to grok for outsiders. But if someone can't figure yout 2010-01-02 then maybe they're not our audience.

---

From: "Yao Jiankang" <[email-masked]>
Date: Wed, 17 Mar 2010 21:59:33 +0800

----- Original Message ----- 
From: "Iljitsch van Beijnum" <[email-masked]>
To: "Phillips, Addison" <[email-masked]>
Cc: "John C Klensin" <[email-masked]>; <[email-masked]>
Sent: Wednesday, March 17, 2010 9:11 PM
Subject: Re: What day is 2010-01-02

> .....
> But if someone can't figure yout 2010-01-02 then maybe they're not our 
> audience.

there are two kinds of audience: those who understand 2010-01-02 by usual 
way and those who understand 2010-01-02 by unusual way.

your logic reasoning seems to be simlar to:

if you don't understand the ietf draft (ietf rfc, ietf discussion, .....), 
you are not ietf audience.

:)

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 17 Mar 2010 16:28:28 +0100

On 17 mrt 2010, at 14:59, Yao Jiankang wrote:

>> But if someone can't figure yout 2010-01-02 then maybe they're not our audience.

> there are two kinds of audience: those who understand 2010-01-02 by usual way and those who understand 2010-01-02 by unusual way.

> if you don't understand the ietf draft (ietf rfc, ietf discussion, .....), you are not ietf audience.

There needs to be a healthy balance between the effort expended to make something clear and the effort expended to understand something. RFCs can get pretty complex. Someone who can't figure out what 2010-01-02 is supposed to mean with all the resources of the internet available to him/her is going to have a hard time understanding RFCs.

An anthropologist may approach the situation open minded and don't make any assumption about whether this is yyyy-mm-dd or yyyy-dd-mm, but anoyone with even the slightest exposure to engineering will understand that the only logical continuation of yyyy- can only be mm-dd.

(Although the exposure to non-standard ways of doing things may make this harder for Americans.)

---

From: Michael Edward McNeil <[email-masked]>
Date: Wed, 17 Mar 2010 09:02:02 -0700

> (Although the exposure to non-standard ways of doing things may make this

Since Americans habitually use month-day order anyway, why would YYYY-MM-DD
be especially difficult for them?  It's Europeans and others who typically
use day-month order that would seem likely to incur difficulties -- except
that putting the year first is a pretty glaring clue that the order
shouldn't be regarded as it usually is for them.

Michael McNeil

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 17 Mar 2010 17:18:45 +0100

> Since Americans habitually use month-day order anyway, why would YYYY-MM-DD be especially difficult for them?  It's Europeans and others who typically use day-month order that would seem likely to incur difficulties -- except that putting the year first is a pretty glaring clue that the order shouldn't be regarded as it usually is for them.

Absolutely. But Americans don't expect this kind of stuff to make sense, because they're used to having a different way of measuring everything, while in the rest of the world we're used to the metric system so we assume things make sense. So an American wouldn't necessarily consider yyyy-dd-mm inconceivable while people from elsewhere probably would and just assume yyyy-mm-dd.

---

From: Bob Hinden <[email-masked]>
Date: Wed, 17 Mar 2010 12:29:58 -0700

On Mar 17, 2010, at 9:02 AM, Michael Edward McNeil wrote:

> On Wed, Mar 17, 2010 at 08:28, Iljitsch van Beijnum <[email-masked]> wrote:
> 

Since this thread is about making things clearer, I would comment on your use of the word "Americans".  Americans means everyone in North and South America.  I suspect what is meant here, is just the USA.

Bob

---

From: Michael Edward McNeil <[email-masked]>
Date: Wed, 17 Mar 2010 13:01:42 -0700

On Wed, Mar 17, 2010 at 12:29, Bob Hinden <[email-masked]> wrote:

> > Since Americans habitually use month-day order anyway, why would
> YYYY-MM-DD be especially difficult for them?  It's Europeans and others who
> typically use day-month order that would seem likely to incur difficulties
> -- except that putting the year first is a pretty glaring clue that the
> order shouldn't be regarded as it usually is for them.
> >
>
> Since this thread is about making things clearer, I would comment on your
> use of the word "Americans".  Americans means everyone in North and South
> America.  I suspect what is meant here, is just the USA.
>
>
Reminds me of a little kid who runs up and proclaims (this actually happened
to me), "I'm not a kid!  Kids are baby goats!"  Well, kids may be baby goats
-- but they're also (sometimes brattish) young humans -- and most speakers
of human languages quickly become cognizant of the fact that every spoken
language has words with more than one accepted meaning, which are perfectly
correct in context, viz.
dictionary.com<http://dictionary.reference.com/browse/American>
:

A·mer·i·can  [uh-*mer*-i-*kuh*n]

1.  of or pertaining to the United States of America or its inhabitants: an
*American* citizen.
2.  of or pertaining to North or South America; of the Western Hemisphere: *the
American continents*.
3.  of or pertaining to the aboriginal Indians of North and South America,
usually excluding the Eskimos....

Hm, I wonder which of those meanings could possibly have been intended here?

Michael McNeil

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 17 Mar 2010 19:06:18 -0600

On Mar 17, 2010, at 2:01 PM, Michael Edward McNeil wrote:

> Reminds me of a little kid who runs up and proclaims (this actually happened to me), "I'm not a kid!  Kids are baby goats!"  Well, kids may be baby goats -- but they're also (sometimes brattish) young humans -- and most speakers of human languages quickly become cognizant of the fact that every spoken language has words with more than one accepted meaning, which are perfectly correct in context, viz. dictionary.com:
> 
> A·mer·i·can  [uh-mer-i-kuhn]
> 
> 1.  of or pertaining to the United States of America or its inhabitants: an American citizen.
> 2.  of or pertaining to North or South America; of the Western Hemisphere: the American continents.
> 3.  of or pertaining to the aboriginal Indians of North and South America, usually excluding the Eskimos....
> 

Canadians like to think of themselves as fairly peaceful people, unless of course, you call them American. Or you are discussing hockey at the Olympics.

---

From: Loa Andersson <[email-masked]>
Date: Wed, 17 Mar 2010 18:22:19 -0700

would Thursday be an acceptable answer?

/Loa

-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 17 Mar 2010 20:00:55 -0700

On 03/17/2010 09:18 AM, Iljitsch van Beijnum wrote:
> Absolutely. But Americans don't expect this kind of stuff to make
> sense, because they're used to having a different way of measuring
> everything, while in the rest of the world we're used to the metric
> system so we assume things make sense. So an American wouldn't
> necessarily consider yyyy-dd-mm inconceivable while people from
> elsewhere probably would and just assume yyyy-mm-dd.

I think you're generalizing to some potentially non-existant superset of
a population that may or may not read internet drafts. I'm really not
sure that's relevant.

A group in my organization (based in the uk no less) was just hosed by a
windows api that represents months using their spelling and is therefore
locale dependant, I'd rather prefer rfc-3339, somehow rather than
worrying that the report for the month of февраль din't get generated.

> Ietf mailing list [email-masked]

---

From: Alfredo Dal´Ava Júnior <[email-masked]>
Date: Thu, 18 Mar 2010 10:25:15 -0300

I'm American from Brazil we always use dd/mm/yyyy :-)
Anyway, in a "computer context" I think that yyyy-mm-dd is a good design,
because I'ts easier to sort and organize by a script in a cronological
order.

As it may cause a lot of confusion, I assume that one way is to use a tag to
identify date format use, like "GMT-3" when we write about time.

---

From: "HUANG, JERRY (ATTLABS)" <[email-masked]>
Date: Wed, 17 Mar 2010 12:51:42 -0400

I agree with Iljitsch's earlier point: In this day and age, if one is
not sure how to interpret 2010-01-02 at first glance, he should have no
trouble figuring it out right away. We would expect people who are
interested in IETF material to have the curiosity to find out, wouldn't
we?

What I am not so sure about is the sweeping statement that Americans
would likely have difficulties with the 'yyyy-mm-dd' format. I walked
around the office and polled seven of my co-workers who happen to be
around (all engineers by trade, five 'natives'), all seven (eight
including me) _know_ what it means. 

Microsoft Windows already allow options to customize 'short date'
presentation in all locales that I spot-checked, one of them is
'yyyy-mm-dd'. 

Perhaps this really is a non-issue after all?

Jerry
--
Jerry Huang, AT&T Labs, +1 630 719 4389

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Iljitsch van Beijnum
> Sent: Wednesday, March 17, 2010 11:19
> To: [email-masked]
> Cc: Yao Jiankang; [email-masked] Discussion
> >> (Although the exposure to non-standard ways of doing things may
make this
> harder for Americans.)
YYYY-MM-
> DD be especially difficult for them?  It's Europeans and others who
> typically use day-month order that would seem likely to incur
difficulties -
> - except that putting the year first is a pretty glaring clue that the
order
> Absolutely. But Americans don't expect this kind of stuff to make
sense,
> because they're used to having a different way of measuring
everything,
> while in the rest of the world we're used to the metric system so we
assume
> things make sense. So an American wouldn't necessarily consider
yyyy-dd-mm
> inconceivable while people from elsewhere probably would and just
assume
> yyyy-mm-dd.

---

From: "YAO Jiankang" <[email-masked]>
Date: Thu, 18 Mar 2010 09:38:15 +0800

----- Original Message ----- 
From: "HUANG, JERRY (ATTLABS)" <[email-masked]>
To: "Iljitsch van Beijnum" <[email-masked]>; <[email-masked]>
Cc: "Yao Jiankang" <[email-masked]>; <[email-masked]>
Sent: Thursday, March 18, 2010 12:51 AM
Subject: RE: What day is 2010-01-02

>including me) _know_ what it means. 

Good test. but you tested it only in your office which, I think , is located in USA.
So the conclusion derived from your office test may apply only to most offices in USA.

Have you tested it in U.K., France, ASIA countries such as Japan, China of different culture and background?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 18 Mar 2010 00:00:42 -0400

Well the US pint is 16 fluid oz which is 1 lb of water. The UK pint is
20 so a pint of water is a pound and a quarter. Go figure.

But since we are on the subject of time, why accept UTC as the basis
for Internet time? Leap seconds are unpredictable and lead to system
errors. The only group with a colorable benefit from leap seconds are
astronomers, the one group that might be expected to be able to fix
leap seconds retrospectively.

The ITU has been discussing plans to abandon leap seconds in
perpetuity, but the astronomers always seem to win in the end. If we
moved from UTC to Internet Time, we could abolish leap seconds.

OK, I am not seriously proposing the IETF try to do this (well not
unless we get into a real fight with the ITU). But if you read some of
the idiotic arguments advanced in favor of introducing random,
unpredictable changes into the measurement of time, they are rather
interesting. There are astronomers who seem to think the earth
revolves around them. There are dire predictions that stopping
fiddling with the time system would be a 'major change'. Every
argument is thrown out, regardless of whether it makes any sense.
People who point out that leap seconds really do cost real money are
poo-pooed as having insignificant importance in such lofty debates.
Quite a few of the protagonists attempt to claim it is only the
ignorance and stupidity of the objectors to leap seconds that makes
them unable to see the reason that they are essential.

Over the course of a year, the length of a day varies by several hours
at this latitude. And the time at which noon occurs varies by several
minutes. And twice a year the state decides that we will all get up an
hour earlier or later. So what benefit are those leap seconds to me?
Absolutely none that I can see.

-- 
-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 18 Mar 2010 12:38:24 -0400

> moved from UTC to Internet Time, we could abolish leap seconds.

This is backwards. Most astronomers I know regard UTC as a nuisance.  
In their calculations, astronomers use TAI (or, if they need to know  
the rotation of the Earth, UT1). Solar system ephemeris work uses  
ephemeris time, for historical reasons (ET − TAI = 32.184 seconds).  
GPS internally uses GPS time, which has the leap second adjustment  
appropriate for the start of the series in 1980, supposedly because  
the GPS program office didn't understand leap seconds (TAI - GPS = 19  
seconds).

The push to create and maintain UTC came primarily from mariners &  
various navies, who wanted to be able to do celestial navigation using  
civil time (i.e., to treat UTC as an approximation of UT1, so that you  
could do km level celestial navigation using time straight from NTP or  
WWV). Now, with GPS/Glonass/Galileo, this seems largely moot.

Now, it is true that Ken Seidelmann is an astronomer, and he is  
against the change, but that is mostly in a "if is isn't broke, don't  
fix it" mode, and also because he is thinking of the long term (in 500  
to 600 years the UT1-TAI offset should be order an hour, and people  
can be expected to start complaining).

The biggest thing stopping any change is apathy (and the  
aforementioned "if is isn't broke, don't fix it").

This site has a lot of information on this subject
http://www.ucolick.org/~sla/leapsecs/nc1985wp7a.html

I used to say that computer time should be TAI (closest to the actual  
clocks, easy to calculate elapsed times), but that never seem to get  
any traction.

Regards
Marshall

>>>> make this harder for Americans.)
>>
>>> YYYY-MM-DD be especially difficult for them?  It's Europeans and  
>>> others who typically use day-month order that would seem likely to  
>>> incur difficulties -- except that putting the year first is a  
>>> pretty glaring clue that the order shouldn't be regarded as it  
>>> usually is for them.
>>

---

From: Ofer Inbar <[email-masked]>
Date: Thu, 18 Mar 2010 11:45:28 -0500

YAO Jiankang <[email-masked]> wrote:
> "HUANG, JERRY (ATTLABS)" <[email-masked]> wrote:
> Have you tested it in U.K., France, ASIA countries such as Japan,
> China of different culture and background?

He was specifically reacting to the statement that *Americans* would
be more likely to have difficulties with this format.  I found that
claim strange myself, since I live in the US and I've never met anyone
who has difficulties with that format.

[ I believe that China uses YYYY-MM-DD anyway, and Wikipedia agrees:
  http://en.wikipedia.org/wiki/Date_and_time_notation_by_country#Greater_China
]

> Perhaps this really is a non-issue after all?

That's about what I said in my other email on this thread: Other than
the email that started this thread, which mentioned a single
individual who found 2010-01-02 ambiguous, I have *NEVER* heard of
anyone finding that format ambiguous.  As I said in that email, I
think we'd need some evidence that there's an actual problem before
it'd be worth discussion a solution.  As far as I can tell, there's
no such evidence, and no problem here.
  -- Cos

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 18 Mar 2010 17:47:10 +0100

On 18 mar 2010, at 17.38, Marshall Eubanks wrote:

> This is backwards. Most astronomers I know regard UTC as a nuisance. In their calculations, astronomers use TAI (or, if they need to know the rotation of the Earth, UT1). Solar system ephemeris work uses ephemeris time, for historical reasons (ET − TAI = 32.184 seconds). GPS internally uses GPS time, which has the leap second adjustment appropriate for the start of the series in 1980, supposedly because the GPS program office didn't understand leap seconds (TAI - GPS = 19 seconds).

Hmm...the signal for the GPS include the difference nowadays, right?

But, the largest problem I think are daylight savings, and the fact the daylight savings rules change.

We should from IETF point of view review the ical spec, and try to push timezone information away from the objects, and to a central repository. The timezone offset should be calculated based on the geographical location of the event.

I.e. if I (or my application) know something happened at 13:32 on 2010-01-02 in Stockholm, that is I claim the best way of stating when something happened. Even better example is 13:32 at 2123-01-02 in Stockholm, as the chance Stockholm still exists in 2123 is higher than Stockholm use the same daylight savings rule then compared with today.

Of course one should be able to say explicit time related to UTC (or TAI ;-) ) as well, but...I am tired of all applications that do the wrong thing. Specifically in user interfaces.

   Patrik

---

From: Michael Edward McNeil <[email-masked]>
Date: Thu, 18 Mar 2010 10:05:45 -0700

2010/3/18 Alfredo Dal´Ava Júnior <[email-masked]>

So, that's how Brazilians refer to themselves and each other:  "I'm an
American"?  And even if so (which I very much doubt), spelled that way as in
American [sic] English?  Yeah, sure.  (If you want to call yourselves
"Americanos" or however it would be spelt in Brazilian Portuguese, be my
guest.)

Best I can see, whenever others object to [U.S.] Americans calling
themselves Americans (who really are the only folks who use that term for
themselves, spelt as in English), it's purely because they want to stick it
to Americans.

Michael McNeil

> As it may cause a lot of confusion, I assume that one way is to use a tag
> to identify date format use, like "GMT-3" when we write about time.
>

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 18 Mar 2010 15:04:06 -0400

On Mar 18, 2010, at 12:47 PM, Patrik Fältström wrote:

>> This is backwards. Most astronomers I know regard UTC as a  
>> nuisance. In their calculations, astronomers use TAI (or, if they  
>> need to know the rotation of the Earth, UT1). Solar system  
>> ephemeris work uses ephemeris time, for historical reasons (ET −  
>> TAI = 32.184 seconds). GPS internally uses GPS time, which has the  
>> leap second adjustment appropriate for the start of the series in  
>> 1980, supposedly because the GPS program office didn't understand  
>> leap seconds (TAI - GPS = 19 seconds).
>

This is the internal time standard. GPS receivers report UTC.

Marshall

> We should from IETF point of view review the ical spec, and try to  
> push timezone information away from the objects, and to a central  
> repository. The timezone offset should be calculated based on the  
> geographical location of the event.
>
> I.e. if I (or my application) know something happened at 13:32 on  
> 2010-01-02 in Stockholm, that is I claim the best way of stating  
> when something happened. Even better example is 13:32 at 2123-01-02  
> in Stockholm, as the chance Stockholm still exists in 2123 is higher  
> than Stockholm use the same daylight savings rule then compared with  
> today.
>
> Of course one should be able to say explicit time related to UTC (or  
> TAI ;-) ) as well, but...I am tired of all applications that do the  
> wrong thing. Specifically in user interfaces.
>
>   Patrik
>

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 18 Mar 2010 20:09:34 +0100

> This is the internal time standard. GPS receivers report UTC.

That was exactly my point. The device get the internal time, and then correct it according to the difference that is overlay in the control channel, and then report UTC?

I.e. one does not have to re-program/re-configure the device(s) every time a leap second is added/removed (added at the moment...).

   Patrik

---

From: Tony Finch <[email-masked]>
Date: Thu, 18 Mar 2010 19:11:46 +0000

On Thu, 18 Mar 2010, Phillip Hallam-Baker wrote:

> Well the US pint is 16 fluid oz which is 1 lb of water.

Not quite, it's about 4% out.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

---

From: Tony Finch <[email-masked]>
Date: Thu, 18 Mar 2010 19:21:35 +0000

> can be expected to start complaining).

UT1 - TAI = 1h is more like 1000 years. See
http://www.ucolick.org/~sla/leapsecs/dutc.html#dutctable

> clocks, easy to calculate elapsed times), but that never seem to get

At the moment it's best to see what the interminable and impenetrable
ITU-R process decides. You never know, the Unix time_t and NTP model of
time might turn out to have been the right thing all along :-)

Tony.

---

From: Tony Finch <[email-masked]>
Date: Thu, 18 Mar 2010 19:25:57 +0000

On Thu, 18 Mar 2010, Patrik Fältström wrote:
>
> We should from IETF point of view review the ical spec, and try to push
> timezone information away from the objects, and to a central repository.
> The timezone offset should be calculated based on the geographical
> location of the event.

Yes. http://fanf.livejournal.com/104586.html

> 2010-01-02 in Stockholm, that is I claim the best way of stating when
> something happened. Even better example is 13:32 at 2123-01-02 in
> Stockholm, as the chance Stockholm still exists in 2123 is higher than
> Stockholm use the same daylight savings rule then compared with today.

Yes, though you need a disambiguation flag for times when the clocks go
back.

In general RFC 3339 (i.e. date + time + UTC offset) is right for recording
timestamps of events that have occurred, but wrong for scheduling human
events in the future.

Tony.

---

From: Alfredo Dal´Ava Júnior <[email-masked]>
Date: Thu, 18 Mar 2010 17:19:03 -0300

I was just referring about one of last posts were someone had a mistake
about "American" definition and South America is "America" too, not only
United States. :)

We call ourself as Brazillian, ou melhor, Brasileiros! :)
In portuguese, the best definition for United States people is
"Estadosunidenses", but it's not very common and that definition is mostly
used in academic range.

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 18 Mar 2010 16:46:09 -0400

On Mar 18, 2010, at 3:05 PM, Phillip Hallam-Baker wrote:

> Well quite, I said that it illustrated the mode of argument, not that
> the arguments were valid.
>
> The arguments made on behalf of 'astronomers' are of course made by
> assertion without bothering to ask what astronomers might think. Every
> time someone proposes removing some archaic piece of junk from the
> Internet specs we have people saying 'but its being used in rural
> Africa'. I saw that argument being made seriously with respect to
> UUNET bang path mail routing when it was finally being euthanized..
>
>
> And the adage 'if it ain't broke don't fix it', is invariably used
> after someone has asserted that something is broken. So a more honest
> version of the usage would be 'If I don't think your problem matters,
> don't fix it'.
>
> The point about the leap seconds is that the same phrase can be used
> to support both the status quo (constantly changing the measurement of
> time in unpredictable ways) and the proposed change (stop adding leap
> seconds).
>
> And people whose interests are in preserving the status quo for the
> sake of the status quo can always dismiss the claims of the people who
> were not at the table when the original decision was made.
>
>
> Unless the earth is slowing down faster than I thought, it would be
> several thousand years before the accumulated error is as much as an
> hour. But since we never use UTC time for daily use, why would this
> matter?

UTC _is_ "clock time" - local time is UTC +- so many hours. That's the  
whole
point of having time zones.

Regards
Marshall

> We always use local time. Making UTC time slip constantly
> means that we need three separate time systems: TAI, UTC and Local
> when all we really need is one fixed series and a second one to make
> up the adjustment.
>

>
> On Thu, Mar 18, 2010 at 12:38 PM, Marshall Eubanks  
> <[email-masked]> wrote:
>>
>> nuisance. In
>> their calculations, astronomers use TAI (or, if they need to know the
>> rotation of the Earth, UT1). Solar system ephemeris work uses  
>> ephemeris
>> time, for historical reasons (ET - TAI = 32.184 seconds). GPS  
>> internally
>> uses GPS time, which has the leap second adjustment appropriate for  
>> the
>> start of the series in 1980, supposedly because the GPS program  
>> office
>> didn't understand leap seconds (TAI - GPS = 19 seconds).
>>
>> various
>> navies, who wanted to be able to do celestial navigation using  
>> civil time
>> (i.e., to treat UTC as an approximation of UT1, so that you could  
>> do km
>> level celestial navigation using time straight from NTP or WWV).  
>> Now, with
>> GPS/Glonass/Galileo, this seems largely moot.
>>
>> against the
>> change, but that is mostly in a "if is isn't broke, don't fix it"  
>> mode, and
>> also because he is thinking of the long term (in 500 to 600 years the
>> UT1-TAI offset should be order an hour, and people can be expected  
>> to start
>> complaining).
>>
>> clocks, easy to calculate elapsed times), but that never seem to  
>> get any
>> traction.
>>
>> Regards
>> Marshall
>>
>>>
>>>>> others who
>>>>> difficulties
>>>> while in the rest of the world we're used to the metric system so  
>>>> we assume

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 18 Mar 2010 15:05:33 -0400

matter? We always use local time. Making UTC time slip constantly

On Thu, Mar 18, 2010 at 12:38 PM, Marshall Eubanks <[email-masked]> wrote:
> This is backwards. Most astronomers I know regard UTC as a nuisance. In
> rotation of the Earth, UT1). Solar system ephemeris work uses ephemeris
> time, for historical reasons (ET - TAI = 32.184 seconds). GPS internally
> uses GPS time, which has the leap second adjustment appropriate for the
> start of the series in 1980, supposedly because the GPS program office
> The push to create and maintain UTC came primarily from mariners & various
> navies, who wanted to be able to do celestial navigation using civil time
> (i.e., to treat UTC as an approximation of UT1, so that you could do km
> level celestial navigation using time straight from NTP or WWV). Now, with
> Now, it is true that Ken Seidelmann is an astronomer, and he is against the
> change, but that is mostly in a "if is isn't broke, don't fix it" mode, and
> UT1-TAI offset should be order an hour, and people can be expected to start
> complaining).
>
> The biggest thing stopping any change is apathy (and the aforementioned "if
> is isn't broke, don't fix it").
>
> clocks, easy to calculate elapsed times), but that never seem to get any
> traction.
>
> Regards
> Marshall
>
>>
>>> Absolutely. But Americans don't expect this kind of stuff to make sense,
>>> because they're used to having a different way of measuring everything,
>>> while in the rest of the world we're used to the metric system so we assume
>>> things make sense. So an American wouldn't necessarily consider yyyy-dd-mm
>>> inconceivable while people from elsewhere probably would and just assume
>>> yyyy-mm-dd.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 18 Mar 2010 15:45:19 -0400

This is something that I have not seen any calendar software do right.
I agree with the argument that time zones for future events should be
strings, not numbers. OK so you might need to do a lookup to
disambiguate, but that is because there is a possibility of change.

I once had a MrCoffee machine which would not make coffee unless the
time was set and would lose the time setting with the least
provocation from the mains supply.

When I used Outlook, it never had the (obvious to me) feature of being
able to specify the local time for a meeting. I used to have recurring
conference calls. Some were based on US time, others on European time.
It is a pretty obvious fact to me that this will cause the meetings to
sometimes recur at different times and this would depend on the time
zone for the meeting, not the time zone my laptop happened to be in at
a particular time.

Equally, I never found a system that was clever enough to work out
that if I take a trip to another time zone, that this should affect
the default meeting times for all the meetings scheduled within the
trip.

I would have imagined that it was a no-brainer for airlines and travel
agencies to work out that they need to take account of local time
correctly. But no, I had an application that was meant to stuff flight
data into my calendar, it invariably did this wrong. Flights from BOS
to SFO would be scheduled for 3 hours duration, flights from SFO to
BOS would be scheduled for 9 hours duration.

People have told me that there are 'hidden problems' in developing a
calendaring spec. If implementations as widely used as Outlook are
unable to manage the obvious problems of simple business trip, I hate
to think what the 'hidden problems might be.