Christmas food on NAO?

[Janis Papanagnou]

Playing on NAO during Christmas is nice; found a lot of candy
already... :-)
2 shortbreads
4 sugar plums
a gingerbread
a chocolate-covered slime mold

Two questions: What other food is implemented? And are the food
probabilities completely adjusted or just a single object type,
say, the slime mold (resp. user defined food), or something like
that diversified?

Janis

[Jonadab the Unsightly One]

Unless it is deliberately obfuscated (e.g., the
strings are encoded in some way), grep appears
to turn up absolutely no indication of this in
nh343-nao.diff, nor anything in the vanilla source.

Is it possible you find player-fruitnamed slime
molds in bones piles? I believe I've seen the
chocolate-covered slime mold previously, in
a non-holiday context (e.g., on the pet- and
fruit-names list, or someplace like that).
Your whole list does seem like a bit too
much of a coincidence, though, unless
somebody bot is deliberately leaving various
themed slime mold bones about.

[Janis Papanagnou]

On 26.12.2012 20:05, Jonadab the Unsightly One wrote:
> Unless it is deliberately obfuscated (e.g., the
> strings are encoded in some way), grep appears
> to turn up absolutely no indication of this in
> nh343-nao.diff, nor anything in the vanilla source.
>
> Is it possible you find player-fruitnamed slime
> molds in bones piles?

Generally that's possible. But it doesn't apply to
the game I reported; there were no bones here.

> I believe I've seen the
> chocolate-covered slime mold previously, in
> a non-holiday context (e.g., on the pet- and
> fruit-names list, or someplace like that).

Maybe there's a patch to take such fruit names. In
this case I'd be interested whether that patch will
be effective on Christmas (this is what I suppose
to be the case), or implemented generally to give
some more flavour to the game. But given the candy
selection posted I suppose it's Christmas specific.

> Your whole list does seem like a bit too
> much of a coincidence, though, unless
> somebody bot is deliberately leaving various
> themed slime mold bones about.

I don't think I've encountered even a single bones
level in this game. The first non-standard fruit I
got from Sokoban(!) where bones definitely won't be
generated. The rest all across the dungeon, but in
neither case a bones. If you can't find it in the
NAO source I suppose because it's some unpublished
special-event code (it will probably be disabled
after 1012-12-26).

You can look up the ttyrecs of my last NAO game if
you're interested in details.

Janis

[rpresser]

On Tuesday, December 25, 2012 10:18:19 PM UTC-5, Janis wrote:
> Playing on NAO during Christmas is nice; found a lot of candy
> already... :-)

See http://bilious.alt.org/~paxed/nethack/yule_nao.diff

[Janis Papanagnou]

Thanks! This explains a lot; effective only 25./26.12., and the
variance seems to only be triggered in the slime mold (or rather
user defined fruit) branch every other time, and in my game I've
obviously got all fruit variants but "candy cane".

Janis

[Pasi Kallinen]

You're off by one day; it's effective on 24th and 25th.

--
Pasi Kallinen
pa...@alt.org
http://bilious.alt.org/ -- NetHack Patch Database

[Janis Papanagnou]

On 31.12.2012 22:31, Pasi Kallinen wrote:
> Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>> On 27.12.2012 21:00, rpresser wrote:
>>> On Tuesday, December 25, 2012 10:18:19 PM UTC-5, Janis wrote:
>>>> Playing on NAO during Christmas is nice; found a lot of candy
>>>> already... :-)
>>>
>>> See http://bilious.alt.org/~paxed/nethack/yule_nao.diff
>>>
>>
>> Thanks! This explains a lot; effective only 25./26.12., and the
>> variance seems to only be triggered in the slime mold (or rather
>> user defined fruit) branch every other time, and in my game I've
>> obviously got all fruit variants but "candy cane".
>>
>
> You're off by one day; it's effective on 24th and 25th.

Oh, I thought that the time type structures would start counting
by 0, so that the coded numbers 24/25 would actually mean 25/26.
(I may be wrong, though.)

Happy New Year to all of you!

Janis

[Capt. Cave Man]

On Mon, 31 Dec 2012 23:31:23 +0200, Pasi Kallinen <pa...@alt.org> wrote:

>Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>> On 27.12.2012 21:00, rpresser wrote:
>>> On Tuesday, December 25, 2012 10:18:19 PM UTC-5, Janis wrote:
>>>> Playing on NAO during Christmas is nice; found a lot of candy
>>>> already... :-)
>>>
>>> See http://bilious.alt.org/~paxed/nethack/yule_nao.diff
>>>
>>
>> Thanks! This explains a lot; effective only 25./26.12., and the
>> variance seems to only be triggered in the slime mold (or rather
>> user defined fruit) branch every other time, and in my game I've
>> obviously got all fruit variants but "candy cane".
>>
>
>You're off by one day; it's effective on 24th and 25th.

Somebody left out the spiked eggnog substitution for a BPoB.

"Wow! This tastes like Nutmeg!"

[Janis Papanagnou]

And I was wrong. I've seen the expression,

(lt->tm_mon == 11 && (lt->tm_mday == 24 || lt->tm_mday == 25))

noticed the 'tm_mon', Dec, defined as "11", so I assumed that 'tm_day'
might as well have the same starting point; but that is not the case.

int tm_mday; /* Day. [1-31] */
int tm_mon; /* Month. [0-11] */

Actually, it seems that *all* 'tm' entries are counted starting from 0
(including "day of week" and "days in year", and "day in month" is the
only one deviating from that rule.

But now I wonder about why 24 and 25 have been chosen. I thought that
depending on the locality Christmas is mainly celebrated on Dec 24 or
alternatively on Dec 25 and Dec 26.

Janis

[James]

On Tuesday, January 1, 2013 12:52:02 AM UTC, Janis wrote:
> On 01.01.2013 00:58, Janis Papanagnou wrote:
> > Oh, I thought that the time type structures would start counting
> > by 0, so that the coded numbers 24/25 would actually mean 25/26.
> > (I may be wrong, though.)

> And I was wrong. I've seen the expression,
> (lt->tm_mon == 11 && (lt->tm_mday == 24 || lt->tm_mday == 25))
> noticed the 'tm_mon', Dec, defined as "11", so I assumed that 'tm_day'
> might as well have the same starting point; but that is not the case.

> int tm_mday; /* Day. [1-31] */
> int tm_mon; /* Month. [0-11] */

> Actually, it seems that *all* 'tm' entries are counted starting from 0
> (including "day of week" and "days in year", and "day in month" is the
> only one deviating from that rule.

Values that are normally numbers in the human readable form have
numeric values which correspond to what one would write. Values
for entities which have names (months, days of the week, etc.)
have numeric values which can be used as indexes into a table
with the name. Since indexing begins with 0 in C++, they also
begin with 0.

--
James

[Jonadab the Unsightly One]

On Dec 31, 7:52 pm, Janis Papanagnou <janis_papanag...@hotmail.com>
wrote:

> But now I wonder about why 24 and 25 have been chosen. I
> thought that depending on the locality Christmas is mainly
> celebrated on Dec 24 or alternatively on Dec 25 and Dec 26.

In the English-speaking world, the 25th is consistently
labeled as "Christmas Day", and the 24th is "Christmas Eve".
Christmas is often *celebrated* for a rather longer period
of time (e.g., all schools in North America close for about
two weeks, and Christmas decorations traditionally start
going up in late November and generally don't come down till
after the first of the year), but on the calendar the only
days labeled with the word "Christmas" are Christmas Eve and
Christmas Day, Dec 24th and 25th.

(I've glossed over the question of Boxing Day because it
doesn't have the word "Christmas" in it. I actually wish
people could make that distinction in America.)

Note that by "English-speaking world" I mean the places
where English is everybody's *first* language. Places where
English is used as a lingua franca often have different
cultural background, related to their first languages.
(Language and culture are distinct phenomena, but they are
closely related and inextricably linked.) It would probably
not be possible for any single build of NetHack to
accommodate all of the cultural variation when it comes to
holidays.

[Janis Papanagnou]

On 01.01.2013 16:16, Jonadab the Unsightly One wrote:
> On Dec 31, 7:52 pm, Janis Papanagnou <janis_papanag...@hotmail.com>
> wrote:
>
>> But now I wonder about why 24 and 25 have been chosen. I
>> thought that depending on the locality Christmas is mainly
>> celebrated on Dec 24 or alternatively on Dec 25 and Dec 26.
>
> In the English-speaking world, the 25th is consistently
> labeled as "Christmas Day", and the 24th is "Christmas Eve".
> Christmas is often *celebrated* for a rather longer period
> of time (e.g., all schools in North America close for about
> two weeks, and Christmas decorations traditionally start
> going up in late November and generally don't come down till
> after the first of the year), but on the calendar the only
> days labeled with the word "Christmas" are Christmas Eve and
> Christmas Day, Dec 24th and 25th.

In Germany, the 25th and 26th are both official Christmas
holidays. Traditional giving of presents are done on 24th,
Christmas Eve, which is a regular workday, but often half
of the day is given free. Pupils have two weeks holidays,
starting just before the 24th. The commercial part start
about with the advent, about four weeks earlier. So it's
quite comparable with what you describe. But, as it seems,
with the exception of the two official free days (25, 26);
the latter also mislead me with the code interpretation.

Janis

[Janis Papanagnou]

Hmm.. - this partly explains why it has been defined inconsistently.
It does not explain the tm_yday (the day number in the year) element,
though, which has no name but is a pure number. In addition I don't
think it is a good design choice to use a 0-based encoding for tm_mon,
since Months are also commonly written using numbers (31.12.2012,
2012-12-31, etc.).

But, without having the cultural background, to think that dates like
"Tue 1. Jan 17:35:02 CET 2013" are "normal" (as opposed to considering
them insane or at least non-sophisticatedly "designed"), I think it's
hard and fruitless to discuss. Also the (low-level machine encoding
concept of) 0-started array indexing is something that's sub-optimal
in case that humans have to handle those numbers. Well.. :-/

Janis

[James]

Hey, this is C. You don't really expect consistency, do you?

> But, without having the cultural background, to think that dates like
> "Tue 1. Jan 17:35:02 CET 2013" are "normal" (as opposed to considering
> them insane or at least non-sophisticatedly "designed"), I think it's
> hard and fruitless to discuss. Also the (low-level machine encoding
> concept of) 0-started array indexing is something that's sub-optimal
> in case that humans have to handle those numbers. Well.. :-/

If you're going to insist that all arrays start with the same
base, then 0 is really the only one which makes sense.
Insisting that all arrays have the same base is a significant
limitation, however; more than once, I've wanted 0 to be in the
middle of the array, with bounds `[-n...n]`
(`[CHAR_MIN...CHAR_MAX]`, for example). _My_ vector classes in
C++ supported this.

And yes, there is a lot of history behind many of these
representations. They really correspond to something that was
appropriate in New Jersey in the 1970's. And not much more.

--
James

[James]

On Tuesday, January 1, 2013 3:16:55 PM UTC, Jonadab the Unsightly One wrote:
> On Dec 31, 7:52 pm, Janis Papanagnou <janis_papanag...@hotmail.com>
> wrote:

> In the English-speaking world, the 25th is consistently
> labeled as "Christmas Day", and the 24th is "Christmas Eve".
> Christmas is often *celebrated* for a rather longer period
> of time (e.g., all schools in North America close for about
> two weeks, and Christmas decorations traditionally start
> going up in late November and generally don't come down till
> after the first of the year), but on the calendar the only
> days labeled with the word "Christmas" are Christmas Eve and
> Christmas Day, Dec 24th and 25th.

You mean that the twelve days of Christmas are really only two?

(Historically, "Christmas" was the twelve days between 25 Dec.
and 6 Jan. Very historically, of course---I suspect that most
modern English speakers would be at a loss if you asked them
what the twelve days of Christmas were.)

--
James

[Janis Papanagnou]

On 01.01.2013 23:44, James wrote:
>
>>>> int tm_mday; /* Day. [1-31] */
>>>> int tm_mon; /* Month. [0-11] */
>
>>>> Actually, it seems that *all* 'tm' entries are counted starting from 0
>>>> (including "day of week" and "days in year", and "day in month" is the
>>>> only one deviating from that rule.
>
>>> Values that are normally numbers in the human readable form have
>>> numeric values which correspond to what one would write. Values
>>> for entities which have names (months, days of the week, etc.)
>>> have numeric values which can be used as indexes into a table
>>> with the name. Since indexing begins with 0 in C++, they also
>>> begin with 0.
>
>> Hmm.. - this partly explains why it has been defined inconsistently.
>> It does not explain the tm_yday (the day number in the year) element,
>> though, which has no name but is a pure number. In addition I don't
>> think it is a good design choice to use a 0-based encoding for tm_mon,
>> since Months are also commonly written using numbers (31.12.2012,
>> 2012-12-31, etc.).
>
> Hey, this is C. You don't really expect consistency, do you?

Well, I generally expect consistency if folks design issues in any
process that lasts more than a weekend. I mean; C is not Intercal!

>
>> But, without having the cultural background, to think that dates like
>> "Tue 1. Jan 17:35:02 CET 2013" are "normal" (as opposed to considering
>> them insane or at least non-sophisticatedly "designed"), I think it's
>> hard and fruitless to discuss. Also the (low-level machine encoding
>> concept of) 0-started array indexing is something that's sub-optimal
>> in case that humans have to handle those numbers. Well.. :-/
>
> If you're going to insist that all arrays start with the same
> base, then 0 is really the only one which makes sense.

Well, no. I don't insist on that. But I also don't think that "0"
would be a good choice. "0" makes only sense in a very "low-level
machine encoding". With array indices I'd think more of the Pascal
way, making any scalar type range a possible subset. But there are
countless other examples (e.g. Algol 68 or Simula, just to name
two that I am also familiar with) that follow a design principle
that is closer to the application domain than close to the machine.
Also, the general concept of numbering items starting with 0 is
broken; I think it's pathological, the "1"st is "0", the "2"nd is
"1", the "3"rd is 2, etc. - Is there anybody who thinks this is
sane? And finally the often mentioned date issue; I mean, if you
start designing date and time representations, would you really
choose something like "Tue 1. Jan 17:35:02 CET 2013" as standard?
I think such (cultural) conventions arise only in isolated regions
of the worlds. :-)

> [...]

>
> And yes, there is a lot of history behind many of these
> representations. They really correspond to something that was
> appropriate in New Jersey in the 1970's. And not much more.

Ah! You said it.

Janis

[Doug Freyburger]

James wrote:
>
> You mean that the twelve days of Christmas are really only two?
>
> (Historically, "Christmas" was the twelve days between 25 Dec.
> and 6 Jan. Very historically, of course---I suspect that most
> modern English speakers would be at a loss if you asked them
> what the twelve days of Christmas were.)

Depends on your history. Yule would have been the twelve days starting
on the night before the solstice - Mothers Night - and ending on New
Years Day. That's probably why January 1 is 12 days after the most
common day the solstice falls on. With Christmas being on Saturnalia on
the 25th beginning anywhere from sundown the night before to dawn of
that day depending on when the day changes per what culture.

[James]

On Wednesday, January 2, 2013 12:15:20 AM UTC, Janis wrote:
> On 01.01.2013 23:44, James wrote:

[...]

> > If you're going to insist that all arrays start with the same
> > base, then 0 is really the only one which makes sense.

> Well, no. I don't insist on that. But I also don't think that "0"
> would be a good choice. "0" makes only sense in a very "low-level
> machine encoding". With array indices I'd think more of the Pascal
> way, making any scalar type range a possible subset. But there are
> countless other examples (e.g. Algol 68 or Simula, just to name
> two that I am also familiar with) that follow a design principle
> that is closer to the application domain than close to the machine.
> Also, the general concept of numbering items starting with 0 is
> broken; I think it's pathological, the "1"st is "0", the "2"nd is
> "1", the "3"rd is 2, etc. - Is there anybody who thinks this is
> sane?

While I far prefer the Pascal approach, 0 works better than 1
for me. It is more technically justified, rather than
applicationally. (Not sure of the right English words there:
technisch vs. fachlich in German.) Since most of my programming
has been low level (data coms, compilers, etc.), I may be
biased. But C *is* a low level language, so 0 definitely seems
appropriate there. (On the other hand, there's really no excuse
for not having arbitrary ranges in C++'s std::vector.)

> And finally the often mentioned date issue; I mean, if you
> start designing date and time representations, would you really
> choose something like "Tue 1. Jan 17:35:02 CET 2013" as standard?

Today, I'd definitly chose the ISO standard as the default, even
if it isn't used everywhere. But in the 1970's, this wasn't an
option. (On the other hand, I can't remember seeing the time
between the day/month and the year anywhere. And I grew up in
some pretty parochial places.)

--
James

[James]

That's an interesting observation about the solstice being 12
days before New Years. And the solstice (and solstice
celebrations) are certainly older than Christmas. On the other
hand, in most of the places I've lived in Europe, its Epiphany
when the Christmas decorations come down. And in some places,
they practically shut down between Christmas and Epiphany.
(In others, of course, its between Christmas and New Years, or
only Christmas and Boxing Day.)

--
James

[Jonadab the Unsightly One]

On Jan 1, 11:47 am, Janis Papanagnou <janis_papanag...@hotmail.com>
wrote:

> > Values that are normally numbers in the human readable
> > form have numeric values which correspond to what one
> > would write. Values for entities which have names
> > (months, days of the week, etc.) have numeric values
> > which can be used as indexes

Incidentally, the localtime() function in Perl does the
same thing. Which is one of the reasons everyone uses
DateTime (and DateTime::Format::Foo) instead.

> It does not explain the tm_yday (the day number in the
> year) element, though,

I've never seen an explanation for that -- not one that
makes any sense, anyway. I think the main problem for me,
in terms of trying to understand this, is that I don't know
of any valid use case for wanting to know the day number
within the year. In my experience nobody EVER writes dates
in any way that involves that number.

> In addition I don't think it is a good design choice to
> use a 0-based encoding for tm_mon, since Months are also
> commonly written using numbers

I don't often defend C, but in this particular case it
actually got something right. Writing months as numbers is
problematic, because it can cause ambiguity, particularly
if you don't happen to know where the person who wrote the
date lives. Depending on locale, a date like 01/02 might
be either Jan 02 or 01 Feb. It's almost as bad as dealing
with pre-Gregorian ("Old Style") dates. Programmers should
NOT be handling date display that way if it can possibly be
avoided, and programming libraries should NOT be designed
to encourage the practice. Returning a zero-based number
that can be used as an index into a (possibly localized)
array of month names or abbreviations is MUCH better than
returning the month as a 1-based month number. (Even
better would be to return a proper DateTime object that
knows how to render itself in short, medium, and long date
formats, taking system l10n settings into account, and will
return the medium format automatically when evaluated in
string context; but C is nowhere near modern enough to do
things that way.)

> But, without having the cultural background, to think
> that dates like "Tue 1. Jan 17:35:02 CET 2013" are
> "normal" (as opposed to considering them insane or at
> least non-sophisticatedly "designed"), I think it's hard
> and fruitless to discuss.

Personally I prefer Tuesday, 2013 Jan 01, 17:35:02 CET, but
both of these forms are at least reasonably clear, because
all parts can be unambiguously identified. The time has
colons, so we know what that is. The year has four digits,
so we know what that is. The month is identifiable (which
it _wouldn't_ be if it were a number), and CET is obviously
the timezone (even though it's not one I'm familiar with),
so the remaining item by process of elimination must be the
day of the month. Claro.

> Also the (low-level machine encoding concept of)
> 0-started array indexing is something that's sub-optimal
> in case that humans have to handle those numbers. Well.. :-/

Ordinary users should be shown a properly formatted date
and/or time. They should NOT be directly seeing the values
in a tm struct. C programmers may need to deal with the
issue, but they presumably can handle it, because compared
to all the arcane low-level things you have to be able to
do in your head to program in C, zero-indexed arrays are
a walk in the park.

[Jonadab the Unsightly One]

On Jan 1, 5:48 pm, James <james.ka...@gmail.com> wrote:

> You mean that the twelve days of Christmas are really only two?

As far as I know, The Twelve Days of Christmas is a song.

[Jonadab the Unsightly One]

On Jan 1, 7:15 pm, Janis Papanagnou <janis_papanag...@hotmail.com>
wrote:

> > Hey, this is C. You don't really expect consistency,
> > do you?
>
> Well, I generally expect consistency if folks design
> issues in any process that lasts more than a weekend. I
> mean; C is not Intercal!

The only consistent thing about C is that it's consistently
arcane. Not totally-over-the-top cartoonishly absurdly
arcane like Intercal, but on the other hand not
significantly less arcane than assembly language.

Most of the functions have names like atoi and fputs and
ldexp and mbtowc. The core language provides NO high-level
data types and an annoying dearth of basic built-in
functions; in particular, there are NO list-operator
functions (map, grep, sort, etc.) There's no automatic
bounds checking and no garbage collection of any kind (not
even refcounting), so almost all memory allocation has to
be handled manually. String length isn't even dynamic,
something BASIC got right way back I don't even know what
decade.

Griping about the fact that C has zero-indexed arrays is
sort of like complaining that N'Sync doesn't make good use
of the cello. It's true, but there are bigger fish to fry.

> > If you're going to insist that all arrays start with
> > the same base, then 0 is really the only one which
> > makes sense.
>
> Well, no. I don't insist on that. But I also don't think
> that "0" would be a good choice. "0" makes only sense in
> a very "low-level machine encoding".

The main difference between C and assembly language is that
C is _ostensibly_ portable. (It would be more accurate to
say that C makes portability _possible_; it certainly does
not automatically provide it like many modern languages.)

> if you start designing date and time representations,
> would you really choose something like "Tue 1. Jan
> 17:35:02 CET 2013" as standard? I think such (cultural)
> conventions arise only in isolated regions of the
> worlds. :-)

All date representations are arbitrary and are tied to
specific cultures. Date representations that use only
numbers are absolutely *horrific* in that regard.

[Jonadab the Unsightly One]

On Jan 2, 11:22 am, Doug Freyburger <dfrey...@yahoo.com> wrote:

> James wrote:
> That's probably why January 1 is 12 days after the most
> common day the solstice falls on.

Actually, I'm pretty sure January starts when it does just
because that's when December ends. January was the
eleventh month originally. The Julian calendar was based
on the Roman military calendar, which started in the spring
when the weather first warmed up enough for the army to
march out. The year didn't start on January first until
somewhat later.

[Janis Papanagnou]

On 03.01.2013 05:07, Jonadab the Unsightly One wrote:
> On Jan 1, 11:47 am, Janis Papanagnou <janis_papanag...@hotmail.com>
> wrote:
>
>> It does not explain the tm_yday (the day number in the
>> year) element, though,
>
> I've never seen an explanation for that -- not one that
> makes any sense, anyway. I think the main problem for me,
> in terms of trying to understand this, is that I don't know
> of any valid use case for wanting to know the day number
> within the year. In my experience nobody EVER writes dates
> in any way that involves that number.

(Be careful with the terms "nobody [does]" and "ever".)

I don't think that the main application would be to write
dates just by giving that number, rather I can imagine that
it's helpful in calculations (like Ascension = Easter + 39
or similar), and specifically if considering leap years.
Having a calculation based on a decomposed form and do all
the details self may not be wise or appropriate.

>
>> In addition I don't think it is a good design choice to
>> use a 0-based encoding for tm_mon, since Months are also
>> commonly written using numbers
>
> I don't often defend C, but in this particular case it
> actually got something right.

(Here we just disagree.)

> Writing months as numbers is
> problematic, because it can cause ambiguity, particularly
> if you don't happen to know where the person who wrote the
> date lives. Depending on locale, a date like 01/02 might
> be either Jan 02 or 01 Feb.

You've got the problem wrongly addressed; the _problem_ here
is that insane mixed date format (that you predominantly see
in the US of America), which has many inherent shortcomings
like mixing order of places for the number groups and using
a shortcut for the year. Those two problems should be fixed
instead of making "hacks" to work around those, and instead
of blaming the use of numbers for months. There's nothing
wrong with 01.02.2013 or 2013-02-01; since (at least with a
non-corrupted mind[*]) you normally would imply an ordering
by significance of number groups.

[*] No offence intended; any mind that is used to some
culturally evolved and educated flaw is prone to take that
flaw as "normal".

> It's almost as bad as dealing
> with pre-Gregorian ("Old Style") dates.

Calendar issues are much more difficult than you may think.
Don't expect the Gregorian calendar to have solved contemporary
time and date issues. It's probably "better" than the Julian
calendar, but if it's going into deceleration of earth events
and irregular leap-seconds introduction, or only in the time
definition difference between GMT and UTC (sic!), there's no
place to speak disparagingly of pre-Gregorian calendars.

> Programmers should
> NOT be handling date display that way if it can possibly be
> avoided, and programming libraries should NOT be designed
> to encourage the practice.

Can't you imagine that in history sciences it might be very
useful to have the choice of invoking different calendars?

> Returning a zero-based number
> that can be used as an index into a (possibly localized)
> array of month names or abbreviations is MUCH better than
> returning the month as a 1-based month number.

But why? - Since numbers *are* used as month representations
on a regular (and, I'd dare to say, even predominant) basis,
there's clearly an advantage to say m=month_name[month_number]
instead of introducing spurious offset-calculations.

Here again, your "advantage" is only one in the context of a
badly designed programming language. A real advantage would
be any formulation that is closer to the problem domain than
to the machine domain.

> [...]

>

>> Also the (low-level machine encoding concept of)
>> 0-started array indexing is something that's sub-optimal
>> in case that humans have to handle those numbers. Well.. :-/
>
> Ordinary users should be shown a properly formatted date
> and/or time. They should NOT be directly seeing the values
> in a tm struct.

Right.

> C programmers may need to deal with the
> issue, but they presumably can handle it, because compared
> to all the arcane low-level things you have to be able to
> do in your head to program in C, zero-indexed arrays are
> a walk in the park.

Those low-level constructs are not hard to understand, that
was not the issue. System and library programmers will also
appreciate that convention, I know that, since I've done that.

But as a programmer you typically want good abstractions, and
not do the low-level calculations and transformations yourself.
That is the point of (higher level) programming languages. And
I had not been the first one who called C just a "high level
assembler"; though C certainly does a quite good job, once you
accept in what league it plays.

But deriving, from the shortcomings of that language, and the
resulting design effects that those have, that those effects
(e.g. 0-based indexing) are the ones that are "good" is way off.

Janis

[Janis Papanagnou]

On 03.01.2013 05:35, Jonadab the Unsightly One wrote:
> On Jan 1, 7:15 pm, Janis Papanagnou <janis_papanag...@hotmail.com>
> wrote:
>>> Hey, this is C. You don't really expect consistency,
>>> do you?
>>
>> Well, I generally expect consistency if folks design
>> issues in any process that lasts more than a weekend. I
>> mean; C is not Intercal!
>
> The only consistent thing about C is that it's consistently
> arcane. Not totally-over-the-top cartoonishly absurdly
> arcane like Intercal, but on the other hand not
> significantly less arcane than assembly language.

Oh, C is an excellent and well readable assembler language.
I have only problems when it comes to looking at it as a
high level language. :-)

>
> [...] String length isn't even dynamic,

> something BASIC got right way back I don't even know what
> decade.

I disagree. First; which "BASIC", since there were tons of
(incomparable) variants. Then I recall that the first string
types had just a 8 bit byte field to allow strings only of
lengths up to only 255 characters. And don't ask for multi-
byte characters or similar.

>
> Griping about the fact that C has zero-indexed arrays is
> sort of like complaining that N'Sync doesn't make good use
> of the cello. It's true, but there are bigger fish to fry.

The 0-base issue was raised in conjunction with mapping
month numbers on month names, where the latter were stored
in (0-based) low-level arrays that require explicit array
index offset calculation to get the mapping right. This is
a *fundamental* problem in C; in my book.

> [...]

>> if you start designing date and time representations,
>> would you really choose something like "Tue 1. Jan
>> 17:35:02 CET 2013" as standard? I think such (cultural)
>> conventions arise only in isolated regions of the
>> worlds. :-)
>
> All date representations are arbitrary

Umm, no. Some are arbitrary; the example above shows the
predominant and widely known form of arbitrariness. I've
seen date representation of quite some cultures, and most
have been quite regular. Predominant worldwide is the DMY
ordering, and population wise also the reverse YMD format.
We can say that (practically) only the USA has this insane
MDY shuffled ordering.
(See http://en.wikipedia.org/wiki/Date_format_by_country.)

(The group delimiters are less an issue; who cares whether
the '/' the '-' or the '.' is used; the important thing is
that unambiguity at least can be derived.)

> and are tied to
> specific cultures. Date representations that use only
> numbers are absolutely *horrific* in that regard.

That perception must be a result of the specific cultural
background as well. :-)

While I've grown up in a region where "12. Jan. 2013" was
the cultural standard, I have no problems with either of
12.02.2013 or 2013-02-12.

Janis

[Patric Mueller]

The cultural background is probably being a programmer.

> While I've grown up in a region where "12. Jan. 2013" was
> the cultural standard, I have no problems with either of
> 12.02.2013 or 2013-02-12.

Of these three date representation, 1 is highly confusable, 2 are how
humans use dates "naturally" somewhere, and 1 is parsable but strange
to humans.

ISO 8601 has so many good properties and it's easily recognizable as
date (as long as they are using the Gregorian calendar) even for
persons who have never seen it before, that I often use it instead of
a more human readable format.

If I really need a "normal" formatted date for human consumption, I
use "3. Jan 2013". I never write the month as number because that is
too ambiguous. Writing the month either abbreviated or not takes that
problem away. Even if it is localized it is recognized as month.

BTW: http://en.wikipedia.org/wiki/Date_format_by_country#Map

Bye
Patric

--
NetHack-De: NetHack auf Deutsch - http://nethack-de.sf.net/

UnNetHack: http://apps.sf.net/trac/unnethack/

[DraconisExtinctor]

On Thu, 03 Jan 2013 10:56:55 +0100, Patric Mueller <bh...@bigfoot.com>
wrote:

And that is why the US military uses that format. whether it is still
followed or required I do not know. But it has been that way here for
well over half a century.

[DraconisExtinctor]

On Thu, 03 Jan 2013 10:56:55 +0100, Patric Mueller <bh...@bigfoot.com>
wrote:

[Jonadab the Unsightly One]

On Jan 3, 12:41 am, Janis Papanagnou <janis_papanag...@hotmail.com>
wrote:

> (Be careful with the terms "nobody [does]" and "ever".)

That's why I tagged on two additional qualifiers.

> I don't think that the main application would be to write
> dates just by giving that number, rather I can imagine that
> it's helpful in calculations (like Ascension = Easter + 39
> or similar),

It would only actually help with that if you could
take the resulting number and convert it back into
a usable tm struct.

> > Writing months as numbers is problematic,

> You've got the problem wrongly addressed; the _problem_ here
> is that insane mixed date format (that you predominantly see
> in the US of America), which has many inherent shortcomings
> like mixing order of places for the number groups and using
> a shortcut for the year.

It's not purely an American problem. In fact, the American
short-date format (mm/dd/yy) would be unambiguous and
not be a problem, if it weren't for the fact that other places
have their own short-date formats, which are different (e.g.,
the British one, dd/mm/yy). The problem is that without
any international consensus on order the numbers are
ambiguous if you don't know what each one represents.

But the order of the individual numbers is based
on the order in which people say the date, which
is inherently cultural -- an l10n issue. It's different
from country to country. If speaking the date, would
you say "January third" or "the third of January"?
If you'd normally say "January third", then you'd
write 1/3; if you'd say "third of January", 3/1.
With no international linguistic unity on which
order to speak in, there's no way to make a
purely numeric date clear to everyone.

> Those two problems should be fixed instead of
> making "hacks" to work around those, and instead
> of blaming the use of numbers for months.

All formats that use numbers for months are ambiguous
and problematic, inherently.

> There's nothing wrong with 01.02.2013

January second, 2013?

> or 2013-02-01;

This works only because nobody ever actually
says the date that way anywhere in the world,
so it's obviously contrived for computer purposes
(to make sorting work without the sort routine
having to parse dates), and thus obviously the
largest units are first, so it's year-month-day.

That's all well and good in email headers, where
the date is written by a computer, but you're never
going to get humans to naturally and consistently
remember to write the date that way, because it
doesn't match the order anyone uses when they
say the date.

> since (at least with a non-corrupted mind[*])
> you normally would imply an ordering
> by significance of number groups.

No, that's what a computer would do.

Humans only use the numbers as shorthand
for what they actually mean, so they write
them in whatever order matches the order
they use when they say the date -- which
depends on their native language. Human
language is so fluid that this can change in
a couple of centuries even in the presence
of a relatively high literacy rate.

> Calendar issues are much more difficult than you
> may think. Don't expect the Gregorian calendar to
> have solved contemporary time and date issues.

It did solve certain ones. For example, with the
Gregorian calendar having been widely adopted,
I can now be pretty sure that February of 2013 is
*before* March of 2013 (not eleven months after
it), regardless of which country the writer lives in.

> but if it's going into deceleration of earth events
> and irregular leap-seconds introduction, or only
> in the time definition difference between GMT
> and UTC (sic!),

Those are fairly minor issues. Being off by a
few seconds only matters if you're doing
something *extremely* time-sensitive, like
high-volume stock trading. For most of us,
a second here or there is much less of a big
deal than being able to figure out whether
we're even talking about the right month.

> Here again, your "advantage" is only one in the
> context of a badly designed programming language.

Well, yes. My preferred way to handle dates is
to let DateTime::Format::Foo handle them for me.
But this is C we're talking about. It doesn't have
things like that.

[jim in austin]

I do a fair amount of ASCII sorts on textual databases, primarily with tools like awk, so I insist upon an 8 digit YYYYMMDD format...

[Janis Papanagnou]

On 03.01.2013 10:56, Patric Mueller wrote:
> Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>> On 03.01.2013 05:35, Jonadab the Unsightly One wrote:
>>
>>> and are tied to
>>> specific cultures. Date representations that use only
>>> numbers are absolutely *horrific* in that regard.
>>
>> That perception must be a result of the specific cultural
>> background as well. :-)
>
> The cultural background is probably being a programmer.

I am not sure about that. Being a programmer and having the task to
manipulate dates certainly will make ISO 8601 look the preferred
representation. But even if you're a normal (non-programmer) human
being; it's confusing if you read something like "11/10/12"! - What
is that supposed to be? That problem is getting apparent once when
people of different cultures talk to each other - and this is not
an uncommon situation nowadays, to say the least.

>
>> While I've grown up in a region where "12. Jan. 2013" was
>> the cultural standard, I have no problems with either of
>> 12.02.2013 or 2013-02-12.
>
> Of these three date representation, 1 is highly confusable, 2 are how
> humans use dates "naturally" somewhere, and 1 is parsable but strange
> to humans.

(You have listed "1" two times; please clarify what you meant.)

Personally I think none of the three is "strange to humans". The
"problem" with the first one is that interaction of people from
different cultures is not that easy since the written month names
will follow a language you may not be familiar with. (The same is
true WRT the names of days in a week; shall people be supposed to
know that "Mon" and "Lun" are the same? Could it be that in some
language there are even name clashes, so that you associate a
different wrong week day, or a different [abbreviated] month.)

>
> ISO 8601 has so many good properties and it's easily recognizable as
> date (as long as they are using the Gregorian calendar) even for
> persons who have never seen it before, that I often use it instead of
> a more human readable format.

(The same here.)

>
> If I really need a "normal" formatted date for human consumption, I
> use "3. Jan 2013". I never write the month as number because that is
> too ambiguous. Writing the month either abbreviated or not takes that
> problem away. Even if it is localized it is recognized as month.

It's recognisable as month, but in trans-national communication you
can't expect to know what that date means; then it's not unambiguous,
and then you need effort, further assumptions, or additional available
meta-information to know how to translate that.

That's why I (try to) always use non-abbreviated forms of ISO dates
in global communication, e.g. if I am posting in Usenet.

Janis

[Jonadab the Unsightly One]

On Jan 3, 1:11 am, Janis Papanagnou <janis_papanag...@hotmail.com>
wrote:

> Oh, C is an excellent and well readable assembler language.

Okay, sure, but it's not significantly _better_ than
assembly language (unless you happen to want to write
code that runs on multiple hardware architectures).

> I have only problems when it comes to looking
> at it as a high level language. :-)

Right. High-level languages have high-level
data types built in. C does not.

> > [...] String length isn't even dynamic, something
> > BASIC got right way back I don't even know what decade.
>
> I disagree. First; which "BASIC",

All the ones I've worked with, I think; but admittedly most
of those are _relatively_ recent, or newer than C at any
rate. (The oldest one I'm sure about is GWBASIC. I did
also work with AppleSoft Basic when I was in junior high,
but I didn't have a computer at home and so knew almost
nothing about programming at that point and did not take
note of what limitations the string type may have had.)

> since there were tons of (incomparable) variants.

True.

> Then I recall that the first string types had just a 8
> bit byte field to allow strings only of lengths up to
> only 255 characters.

I don't think I ever worked with a BASIC that had these
limitations. More to the point, even in the old
line-number BASICs you could insert things into the
middle of a string without worrying about overflowing
the allocated memory. That would be a problem in C.

Of course, modern languages all have regex-based
substitution operations, so strings *have* to be
dynamic.

> And don't ask for multi- byte characters or similar.

Multi-byte character support is newer even than Perl.
(Perl has full-blown Unicode support now, of course,
but it didn't in the early days, because nothing did
back then. Even the early versions of Perl5 had only
experimental Unicode support; it wasn't really solid
until I think 5.6 or so IIRC.)

Come to think of it, I don't think even Ruby had
full-blown Unicode when it first came out.

> > Griping about the fact that C has zero-indexed arrays
> > is sort of like complaining that N'Sync doesn't make
> > good use of the cello. It's true, but there are bigger
> > fish to fry.
>
> The 0-base issue was raised in conjunction with mapping
> month numbers on month names, where the latter were
> stored in (0-based) low-level arrays

0-based low-level arrays are what C has, because it doesn't
have any high-level data types. This is a valid complaint
against C in general, but it doesn't have anything really
specifically to do with how the tm struct is set up.

> > All date representations are arbitrary
>
> Umm, no.

Umm, yes. In the first place, all date representations
rely on the selection of an arbitrary epoch. Then,
building on that, even if we accept the _length_ of a year
as being non-arbitrary because it's based on a physical
phenomenon, the question of when to start the beginning of
each year is highly arbitrary. Why doesn't the year start
on midsummer, for example? When the _day_ starts is
problematic as well: some ancient cultures started the day
at sundown, but now we use midnight. Why? Because
somebody chose it, that's why. There's nothing _wrong_
with this choice, but it _is_ an arbitrary choice. Some
months have more days than others; which are which is
completely arbitrary. Why do leap days happen in the
second month of the year, instead of the last? Why do we
have leap _days_, instead of waiting and eventually having
a leap week or a leap month? Why is the day divided into
24 (or more precisely 12+12) hours?

The least arbitrary date-keeping mechanism I can think of
involves plank time, but you still need an arbitrary epoch,
and the numbers would be totally unwieldy, and I can't
imagine anyone wanting to use such a system, not even
particle physicists.

> Predominant worldwide is the DMY ordering, and population
> wise also the reverse YMD format.

And to have one format for everyone you'd have to choose
between them. How could you make the choice, if not
arbitrarily?

> We can say that (practically) only the USA has this
> insane MDY shuffled ordering.

Why is MDY more insane than DMY? Either one of them has to
be parsed if you want to do any kind of cronological sort.

> (The group delimiters are less an issue;

Agreed.

> the important thing is that unambiguity at least can be
> derived.)

Not with just numbers, it can't. If you *label* the
numbers, then it's clear. (This approach is used e.g., in
Japan.) Alternately, if you don't like labels, you can use
names instead of numbers for some of the components, most
commonly for the month.

> > and are tied to specific cultures. Date
> > representations that use only numbers are absolutely
> > *horrific* in that regard.
>
> That perception must be a result of the specific cultural
> background as well. :-)
>
> While I've grown up in a region where "12. Jan. 2013" was
> the cultural standard, I have no problems with either of
> 12.02.2013 or 2013-02-12.

But how do you feel about 1/12/13 or (I've actually seen
this proposed) 1/12/113?

And when you say that DMY and YMD are both "not shuffled",
you are completely ignoring the quite common issue of
listing date and time together. To be consistent, you
would have to insist that with YMD the time always be
listed after the date and with DMY the time be listed
before the date, ss:mm:hh. Otherwise your order is
"shuffled". Oh, no, your date format is insane!

[Janis Papanagnou]

On 03.01.2013 14:15, Jonadab the Unsightly One wrote:
> On Jan 3, 12:41 am, Janis Papanagnou <janis_papanag...@hotmail.com>
> wrote:

>> Jonadab the Unsightly One wrote:
>>

>>> Writing months as numbers is problematic,
>
>> You've got the problem wrongly addressed; the _problem_ here
>> is that insane mixed date format (that you predominantly see
>> in the US of America), which has many inherent shortcomings
>> like mixing order of places for the number groups and using
>> a shortcut for the year.
>
> It's not purely an American problem. In fact, the American
> short-date format (mm/dd/yy) would be unambiguous and
> not be a problem, if it weren't for the fact that other places
> have their own short-date formats, which are different (e.g.,
> the British one, dd/mm/yy).

"11/10/12" is not ambiguous?! - Certainly it is! And this has
nothing to do with countries writing the same date as "10/11/12",
which is *also* an ambiguous representation.

> The problem is that without
> any international consensus on order the numbers are
> ambiguous if you don't know what each one represents.

Sure, if countries consent to a common representation that would
simplify issues. But that is not the case. So we should judge by
objective criteria which representation fit best and unambiguously.
One criterion is an unabbreviated year. Another one is a natural
(non-shuffled) ordering of number groups according to their weight.
Last but not least, restricting from using locale specific words.

Also worldwide(!) common usage gives an indication what are more
appropriate formats. (I've posted a link to the distribution of
date/time representation upthread.)

>
> But the order of the individual numbers is based
> on the order in which people say the date, which
> is inherently cultural -- an l10n issue. It's different
> from country to country. If speaking the date, would
> you say "January third" or "the third of January"?
> If you'd normally say "January third", then you'd
> write 1/3; if you'd say "third of January", 3/1.

I agree with you that the culture/language will influence that.

But now we live in a global world, people from different cultures
talk to each other. And we have the advantage that there's already
a standard defined, ISO 8601; and this is a Good Standard.[*]

[*] Mind, I say this despite it's *not* reflecting _my_ cultural
common usage. Nonetheless I am able to recognise its advantages.

> With no international linguistic unity on which
> order to speak in, there's no way to make a
> purely numeric date clear to everyone.

I disagree. We certainly don't need a worldwide common lingua to
use a common date format if we communicate to each other; it is
sufficient to use a sophisticatedly designed date representation.
And luckily we already have that, meanwhile even for decades.

>
>> Those two problems should be fixed instead of
>> making "hacks" to work around those, and instead
>> of blaming the use of numbers for months.
>
> All formats that use numbers for months are ambiguous
> and problematic, inherently.
>
>> There's nothing wrong with 01.02.2013
>
> January second, 2013?
>
>> or 2013-02-01;
>
> This works only because nobody ever actually
> says the date that way anywhere in the world,
> so it's obviously contrived for computer purposes

No, that's not true. That works because it makes sense, because
it's a _regular_ representation.

> (to make sorting work without the sort routine
> having to parse dates), and thus obviously the
> largest units are first, so it's year-month-day.

While it's true that it simplifies sorting - and sorting had been
one point that is listed in the list of advantages -, hereabouts
where I live they introduced that format as an (alternative) form
_wherever you type texts_; at that time they had also ordinary
mechanical typewriters in mind where "sorting" of dates was not
only not an issue, it was just not possible on paper and in books.

And also read about its rationale (I've borrowed the text from
wikipedia; http://en.wikipedia.org/wiki/ISO_8601):
"The purpose of this standard is to provide an unambiguous and
well-defined method of representing dates and times, so as to
avoid misinterpretation of numeric representations of dates and
times, particularly when data is transferred between countries
with different conventions for writing numeric dates and times."
(No "computers" mentioned. Not even in any significant context in
the whole article, BTW.)

The ISO standard says:
"Each representation can be easily recognized, which is beneficial
when human interpretation is required."
The humans (not computers) are primary target clients, and avoiding
interpretation problems the goal! (Systems are mentioned later.)

>
> That's all well and good in email headers, where
> the date is written by a computer, but you're never
> going to get humans to naturally and consistently
> remember to write the date that way, because it
> doesn't match the order anyone uses when they
> say the date.

Again, not true. If you say that _you_ have problems, well, so be
it.

>
>> since (at least with a non-corrupted mind[*])
>> you normally would imply an ordering
>> by significance of number groups.
>
> No, that's what a computer would do.

It's very advantageous for computers. But it is more than that; if
you communicate with someone outside the US of America, generally,
if people from two countries communicated with each other - and by
communication I do not only mean Mail, Web and Usenet - you should
use some representation that has some sensible criteria and/or is
some consented (international) standard or convention; ISO 8601 is
exactly that.

>
> Humans only use the numbers as shorthand
> for what they actually mean, so they write
> them in whatever order matches the order
> they use when they say the date -- which
> depends on their native language. Human
> language is so fluid that this can change in
> a couple of centuries even in the presence
> of a relatively high literacy rate.

(Again, be careful with generalising terms like "humans [do]".)

> [...]

>
>> but if it's going into deceleration of earth events
>> and irregular leap-seconds introduction, or only
>> in the time definition difference between GMT
>> and UTC (sic!),
>
> Those are fairly minor issues. Being off by a
> few seconds only matters if you're doing
> something *extremely* time-sensitive, like
> high-volume stock trading.

The point is that the errors accumulate. The Julian calendar was
initially also "sufficiently correct" to reflect the astronomical
facts with the day unit counting; until the errors accumulated and
they observed that they need something more accurate. Leap-seconds
is the same issue, just on a finer scale. There still is no final
universal calendar existing, because there can't be one; you need
always adjustments - as long as you stay in a sun/earth centred
interpretation, but given what we know about the universe, also if
we extend the date to some "universal" date and time[*] concept.

Janis

PS: Frankly, I get tired talking with citizens of the USA about
sensible standards; time and date, SI units, etc. So I hope we
have all said and can abstain from extending on that [off-]topic.

> [...]

[*] As a related note aside; remember how time had been defined
half a decade ago, and how it is now defined; Caesium atomic
oscillations!

[Janis Papanagnou]

On 03.01.2013 20:45, Jonadab the Unsightly One wrote:
> On Jan 3, 1:11 am, Janis Papanagnou <janis_papanag...@hotmail.com>
> wrote:
>
>> Oh, C is an excellent and well readable assembler language.
>
> Okay, sure, but it's not significantly _better_ than
> assembly language (unless you happen to want to write
> code that runs on multiple hardware architectures).

Crap! - I've programmed in the past decades with about a dozen
assemblers (with different underlying machine architectures). -
There is a significant difference, and very obvious. I wonder
what drives you to make such a nonsensical claim.

> [...]

>
>> Then I recall that the first string types had just a 8
>> bit byte field to allow strings only of lengths up to
>> only 255 characters.
>
> I don't think I ever worked with a BASIC that had these
> limitations. More to the point, even in the old
> line-number BASICs you could insert things into the
> middle of a string without worrying about overflowing
> the allocated memory. That would be a problem in C.

Aha, I see where you're coming from.

>
> Of course, modern languages all have regex-based
> substitution operations, so strings *have* to be
> dynamic.
>
>> And don't ask for multi- byte characters or similar.
>

> Multi-byte character support is newer even than Perl. [...]

I don't recall when it was that multi-byte characters had
been introduced in IT; I'd have thought it was earlier.

>
>>> All date representations are arbitrary
>>
>> Umm, no.
>
> Umm, yes. In the first place, all date representations
> rely on the selection of an arbitrary epoch. Then,
> building on that, even if we accept the _length_ of a year
> as being non-arbitrary because it's based on a physical
> phenomenon, the question of when to start the beginning of
> each year is highly arbitrary. Why doesn't the year start
> on midsummer, for example? When the _day_ starts is
> problematic as well: some ancient cultures started the day
> at sundown, but now we use midnight. Why? Because
> somebody chose it, that's why. There's nothing _wrong_
> with this choice, but it _is_ an arbitrary choice. Some
> months have more days than others; which are which is
> completely arbitrary. Why do leap days happen in the
> second month of the year, instead of the last? Why do we
> have leap _days_, instead of waiting and eventually having
> a leap week or a leap month? Why is the day divided into
> 24 (or more precisely 12+12) hours?

Slow down! - You said: "All date representations are arbitrary",
and we have been talking about current dates, regular ones, and
irregular ones, not about historic dates. (In history you will
always find irregularities, in any area, and on any topic.)

If you'd have wanted to point out that in some small isolated
region there *still* exist different calendars, deviating from
the common convention, I'd agree with you. But that is not that
relevant in a claim starting with "All" and ending in "arbitrary".

>
> [...]

>
>> Predominant worldwide is the DMY ordering, and population
>> wise also the reverse YMD format.
>
> And to have one format for everyone you'd have to choose
> between them. How could you make the choice, if not
> arbitrarily?

The primary issue is to unambiguously understand the intention of
the represented date. It's of minor relevance WRT interpretation
errors and misunderstandings if you see 2013-01-02 and 2012-1-2
and 2012/1/2, or, 2.1.2012 and 02.01.2013 and 02/01/2013.

Restricting a date representation further by specifying a concrete
syntax completely will further simplify interpretation, specifically
if automated processing is done (but even there it's not necessary
in any case, since it's not uncommon to have sophisticated parsers;
instead of \d{4}-\d{2}-\d{2} you could write \d{1-4}[-/.]\d{1-2}...).

>
>> We can say that (practically) only the USA has this
>> insane MDY shuffled ordering.
>
> Why is MDY more insane than DMY?

(I've thoroughly explained that. If you still ask this question,
I'll bite.)

> Either one of them has to
> be parsed if you want to do any kind of cronological sort.
>

[...]

>
>> the important thing is that unambiguity at least can be
>> derived.)
>
> Not with just numbers, it can't.

If you write 2013 you know at least that it must be a year.
Now the only thing that you need to presume is the existence of
a _regular_ ordering. Then the position of the M and D are clear;
either 2013-M-D or D.M.2013 - ("big endian" or "little endian").
For the whole world[*] this is clear, see the posted reference
for the table and the world map.

[*] Well, for the whole world but the US of America, obviously.

> If you *label* the
> numbers, then it's clear. (This approach is used e.g., in
> Japan.) Alternately, if you don't like labels, you can use
> names instead of numbers for some of the components, most
> commonly for the month.

Oh, if you mean something like y:2013 m:01 d:12, then there's
something to say about that. First, labels are locale dependent,
so again not very appropriate for that purpose. Then, they are
also unnecessary, since all we need is just regularly ordered
numbers. (We have that convention in many places; time, money,
just to name two prominent ones.)

(If I buy something I have to pay "2.45", or, "two fourty five".
In your culture, do we need to say "two dollars, fourty five
cents"? Would foreigners have to expect that "2.45" means "45
dollars and 2 cents"? No. We assume and have a natural ordering.)

(Labels are interesting, e.g. in programming, when you want to
shuffle elements in case order is _insignificant_; parameters
(in perl?), for example. I think it is a good idea to support
such concepts in programming, in the design of languages, where
function parameters are involved. But that is a different topic.)

>
>>> and are tied to specific cultures. Date
>>> representations that use only numbers are absolutely
>>> *horrific* in that regard.
>>
>> That perception must be a result of the specific cultural
>> background as well. :-)
>>
>> While I've grown up in a region where "12. Jan. 2013" was
>> the cultural standard, I have no problems with either of
>> 12.02.2013 or 2013-02-12.
>
> But how do you feel about 1/12/13 or (I've actually seen
> this proposed) 1/12/113?

The former case has the problem that it's not unambiguous;
without a 4-digit year you can't, in the general case, tell
dates apart (example: 11/12/10, which could six possible
interpretations, but given that in the world you have only
three of the six permutations "implemented", even if you
assume regular ordering (i.e. exclude the US aberration),
you still have two possible interpretations). A precondition
for a universal format would, in my book, always have four
digits. (The possibilities of abbreviation in ISO 8601 with
using hyphens, I dislike. But I accept that, since the goal
to internationally talk to each other unambiguously is still
achieved.)

WRT "1/12/113" - I don't know where you got that from or what
it shall mean. - There are alternative day definitions in the
ISO 8601 standard that come close; "2013/042" is the 42th day
in the year 2013. But I suppose you intended to say something
else with your question?

>
> And when you say that DMY and YMD are both "not shuffled",
> you are completely ignoring the quite common issue of
> listing date and time together.

No, I have not been ignoring that. I was focussing on what
I think has been the primary misconception.

> To be consistent, you
> would have to insist that with YMD the time always be
> listed after the date and with DMY the time be listed
> before the date, ss:mm:hh. Otherwise your order is
> "shuffled". Oh, no, your date format is insane!

(Please don't play the ridiculous. Let's discuss is on a
rationale basis as we did before.)

In case that you have an _isolated_ date representation, any
regular (non-shuffled) form will be understandable. Since
_time_ has three 2-digit components, we don't have the option
to turn around the order of the digit groups; but we also
don't need to do that. Time seems to be predominantly written
in the most-significant-group-first order; even in the USA
(but note that, again, we have also the notational AM/PM
aberration in that cultural area).

In case we have _combined_ date/time representations, we
should address that by using the ISO 8601 format; which is
regular.

But note that the ISO format requires a 'T' as conjunction
of the two parts, as in "2013-01-12T12:46". So it may look
better (for a human reader) to consider those as two parts;
"2013-01-12" and "12:46". What I (in programming) regularly
do is to use a readable separator "2013-01-12_12:46", but
in human communication you want the two pieces apart anyway,
so you'd usually write something like "on 2013-01-12, 12:46",
or similar, with comma, spaces, etc.

Janis

[rpresser]

On Thursday, January 3, 2013 4:32:03 PM UTC-5, Janis wrote:

[snip entire discussion on formats and sanity]

Janis, if you say in one message "some formats are insane, but not
others", then qualify it by saying "what I mean is, some formats are
far easier to understand TODAY because they are widely used", then
use of the word insane is just inflammatory.

Date formats are conventions agreed upon by people. There are
reasons why some formats are preferred, and unreasonable accidents
of history why other formats are preferred elsewhere. To call any of
them insane is just being bigoted. Of course, a certain amount of
bigotry is useful, in that it discourages use of deliberately
ridiculous calendars:

> The Illuminati Calendar is based on five seasons (due to the Law
> of Fives.) The names of the seasons, their meanings & equivalent
> dates are as follows: Verwirrung: Season of Chaos Jan. 1 - Mar.
> 14 Zweitracht: Season of Discord Mar. 15 - May 2 Unordnung:
> Season of Confusion May 27 - Aug. 7 Beamtenherrschaft: Season of
> Bureaucracy Aug.8-Oct.19 Grummet: Season of Aftermath Oct. 20 -
> Dec. 31 *
>
> Each of the 5 Seasons is divided into 5 months, producing a year
> of 25 months. The first 3 months of every season (known as the
> tricycle) each have 15 days. The last 2 months of each season
> (the bicycle) have 14 days. The last day of each season is called
> Eye Day and is celebrated in foul and mysterious ways. Everything
> is dated from the year 1 A.M. (Anno Mung), which is 4000 B.C.E. -
> The Year Hung Mung first perceived the Sacred Chao and achieved
> illumination.

Today is Pungenday, the 3rd day of Chaos in the YOLD 3179.

[rpresser]

On Thursday, January 3, 2013 3:03:01 PM UTC-5, Janis wrote:

> PS: Frankly, I get tired talking with citizens of the USA about
> sensible standards; time and date, SI units, etc. So I hope we
> have all said and can abstain from extending on that [off-]topic.

Admitted bigotry.

Repeating myself: there are reasons why people agree on standards,
and historical accidents of history why people cling to standards.
To call some "sensible" and others "nonsense" is bigotry - whether
it is the bigotry of clinging, or the bigotry of preferring the
majority, or the bigotry of calling people stupid for disagreeing
or not understanding your point.

Please *try* to use less inflammatory language.

[James]

On Thursday, 3 January 2013 06:11:07 UTC, Janis wrote:
> On 03.01.2013 05:35, Jonadab the Unsightly One wrote:
>
> > On Jan 1, 7:15 pm, Janis Papanagnou <janis_papanag...@hotmail.com>

> > [...] String length isn't even dynamic,
> > something BASIC got right way back I don't even know what
> > decade.

> I disagree. First; which "BASIC", since there were tons of
> (incomparable) variants. Then I recall that the first string
> types had just a 8 bit byte field to allow strings only of
> lengths up to only 255 characters. And don't ask for multi-
> byte characters or similar.

The Basics I remember only allowed two character variable names,
the first of which had to be a letter (case insensitive), and
the second (if present) a digit. (That's right: a maximum of
286 variables.) And the type was defined by a posfixed $ or
some such.

Also no looping constructs other than a very limited for, no
blocks for if (so you had to use goto), no parameters for
functions, etc., etc.

Given all that, who's worrying about string handling?

> > Griping about the fact that C has zero-indexed arrays is
> > sort of like complaining that N'Sync doesn't make good use
> > of the cello. It's true, but there are bigger fish to fry.

> The 0-base issue was raised in conjunction with mapping
> month numbers on month names, where the latter were stored
> in (0-based) low-level arrays that require explicit array
> index offset calculation to get the mapping right. This is
> a *fundamental* problem in C; in my book.

I don't see where it's a problem. I can think of a lot of worse
things in C. If you include the libraries, there's always
gets. But the absense of a true boolean would be significant as
well. And more generally, the syntax itself, and the large
amount of undefined behavior. And the broken arrays.

Many of these issues are understandable *if* you know the
history of C, and are familiar with B (from which it came); my
impression is that typing was really only added in order to
support byte addressing (and an 8 bit character type). And the
syntax was designed to allow programs to be written with as few
characters as possible, with almost every ASCII character
overloaded to do something. (Developed with teletypes in mind?
Where every character output causes a loud noise.)

> > [...]

> >> if you start designing date and time representations,
> >> would you really choose something like "Tue 1. Jan
> >> 17:35:02 CET 2013" as standard? I think such (cultural)
> >> conventions arise only in isolated regions of the
> >> worlds. :-)

> > All date representations are arbitrary

> Umm, no. Some are arbitrary; the example above shows the
> predominant and widely known form of arbitrariness. I've
> seen date representation of quite some cultures, and most
> have been quite regular. Predominant worldwide is the DMY
> ordering, and population wise also the reverse YMD format.
> We can say that (practically) only the USA has this insane
> MDY shuffled ordering.

There are different degrees of arbitrariness. One would expect
either big-endian or little-endian, which means that usual US
conventions are a bit unusual. But the date format we're
complaining about is:

Fri Jan 4 09:31:55 GMT 2013

In other words: weekday month day time timezone year. Even
growing up in America, I don't recall anyone inserting the time
between the month/day and the year. I don't think this format
is used anywhere outside of New Jersey, and probably not there,
except in the old Bell Labs.

> While I've grown up in a region where "12. Jan. 2013" was
> the cultural standard, I have no problems with either of
> 12.02.2013 or 2013-02-12.

I've lived in four different countries, and my wife comes from
a fifth, and all but the US use something very similar to the
first, above, except the US. (Curiously, in the UK, I might say
"January tenth", but I'd write it "10 January".) For whatever
reasons, little endian seems almost universal for dates outside
the computer world, with the US the only exception. The choice
of big endian for the ISO date standard is probably motivated by
the desire for trivial machine sorting (and perhaps by not
wanting to use any existing cultural format, so as not to seem
to be favoring that culture, or to be anti some other culture).

--
James

[James]

On Thursday, 3 January 2013 19:45:38 UTC, Jonadab the Unsightly One wrote:
> On Jan 3, 1:11 am, Janis Papanagnou <janis_papanag...@hotmail.com>
> wrote:
> > > [...] String length isn't even dynamic, something
> > > BASIC got right way back I don't even know what decade.

> > I disagree. First; which "BASIC",

> All the ones I've worked with, I think; but admittedly most
> of those are _relatively_ recent, or newer than C at any
> rate. (The oldest one I'm sure about is GWBASIC. I did
> also work with AppleSoft Basic when I was in junior high,
> but I didn't have a computer at home and so knew almost
> nothing about programming at that point and did not take
> note of what limitations the string type may have had.)
> > since there were tons of (incomparable) variants.

> True.

> > Then I recall that the first string types had just a 8
> > bit byte field to allow strings only of lengths up to
> > only 255 characters.

> I don't think I ever worked with a BASIC that had these
> limitations. More to the point, even in the old
> line-number BASICs you could insert things into the
> middle of a string without worrying about overflowing
> the allocated memory. That would be a problem in C.

I've never seen a Basic which allowed insertion, or modifying
a string in any way. The only way to change the value of
a string variable was to assign a new string to it. What they
did support was concatenation. And they did manage the memory
involved automatically, and would give you a controlled error
(rather than undefined behavior) if they ran out of memory.

And I think your point is not that you cannot overflow memory;
try to build a long enough string, and you will. The point is
that the language will automatically grow or shrink the memory
used, and will generate a defined error condition if the memory
is exhausted.

> Of course, modern languages all have regex-based
> substitution operations, so strings *have* to be
> dynamic.

I don't think so. C++ makes this mistake, but in Java, String
objects are immutable (as they should be).

> > And don't ask for multi- byte characters or similar.

> Multi-byte character support is newer even than Perl.
> (Perl has full-blown Unicode support now, of course,
> but it didn't in the early days, because nothing did
> back then. Even the early versions of Perl5 had only
> experimental Unicode support; it wasn't really solid
> until I think 5.6 or so IIRC.)

Multi-byte characters are far older than Unicode. One of the
original motivations for Unicode was to obliviate the need for
them, by using 16-bit characters.

--
James

[James]

On Thursday, 3 January 2013 04:07:58 UTC, Jonadab the Unsightly One wrote:
> On Jan 1, 11:47 am, Janis Papanagnou <janis_papanag...@hotmail.com>
> wrote:

[...]

> I don't often defend C, but in this particular case it
> actually got something right. Writing months as numbers is
> problematic, because it can cause ambiguity, particularly
> if you don't happen to know where the person who wrote the
> date lives. Depending on locale, a date like 01/02 might
> be either Jan 02 or 01 Feb. It's almost as bad as dealing
> with pre-Gregorian ("Old Style") dates. Programmers should
> NOT be handling date display that way if it can possibly be
> avoided, and programming libraries should NOT be designed
> to encourage the practice. Returning a zero-based number
> that can be used as an index into a (possibly localized)
> array of month names or abbreviations is MUCH better than
> returning the month as a 1-based month number. (Even
> better would be to return a proper DateTime object that
> knows how to render itself in short, medium, and long date
> formats, taking system l10n settings into account, and will
> return the medium format automatically when evaluated in
> string context; but C is nowhere near modern enough to do
> things that way.)

It's a difficult problem. One could argue that "1" is always
January, where as "Jan" is locale dependent. But since there
will almost certainly be other locale dependent elements in any
output (labels, etc.), you *are* outputting to a specific
locale. On the other hand, with the exception of the US, every
locale has a specific order for dates, that you can count on: if
the labels are in French or German, 1/2/2013 isn't ambiguous.
Nor is it ambiguous if the labels use British spelling in
English (but they might not contain a word where the spelling is
different). It's only a problem in the US locale, where
different communities (mainly military use DMY, and every where
else YMD) use different standards for the date, but not for
anything else.

> > But, without having the cultural background, to think
> > that dates like "Tue 1. Jan 17:35:02 CET 2013" are
> > "normal" (as opposed to considering them insane or at
> > least non-sophisticatedly "designed"), I think it's hard
> > and fruitless to discuss.

> Personally I prefer Tuesday, 2013 Jan 01, 17:35:02 CET, but
> both of these forms are at least reasonably clear, because
> all parts can be unambiguously identified. The time has
> colons, so we know what that is. The year has four digits,
> so we know what that is. The month is identifiable (which
> it _wouldn't_ be if it were a number), and CET is obviously
> the timezone (even though it's not one I'm familiar with),
> so the remaining item by process of elimination must be the
> day of the month. Claro.

It's clear, but it is somewhat surprising, since I don't think
this format was ever used outside the Unix community.

--
James

[James]

On Thursday, 3 January 2013 13:15:25 UTC, Jonadab the Unsightly One wrote:
> On Jan 3, 12:41 am, Janis Papanagnou <janis_papanag...@hotmail.com>

[...]

> > You've got the problem wrongly addressed; the _problem_ here
> > is that insane mixed date format (that you predominantly see
> > in the US of America), which has many inherent shortcomings
> > like mixing order of places for the number groups and using
> > a shortcut for the year.

> It's not purely an American problem. In fact, the American
> short-date format (mm/dd/yy) would be unambiguous and
> not be a problem, if it weren't for the fact that other places
> have their own short-date formats, which are different (e.g.,
> the British one, dd/mm/yy). The problem is that without
> any international consensus on order the numbers are
> ambiguous if you don't know what each one represents.

Even in the US, there is a difference between what is used in
the Military and elsewhere.

Note that if the US were some small country using a language
that no one else used, we wouldn't care about it. Dates are
locale specific, and would be unambigous in the given locale.
It's the widespread use of English, and the fact that many
English speaking locales use the DMY format which causes the
problem.

> But the order of the individual numbers is based
> on the order in which people say the date, which
> is inherently cultural -- an l10n issue. It's different
> from country to country. If speaking the date, would
> you say "January third" or "the third of January"?
> If you'd normally say "January third", then you'd
> write 1/3; if you'd say "third of January", 3/1.
> With no international linguistic unity on which
> order to speak in, there's no way to make a
> purely numeric date clear to everyone.

That's simply false. Where I work, we say "January tenth", but
write "10 January". In the US, you say "five dollars", but
write "$5". In Arabic, reading from left to right, numbers
appear little-endian, but they are pronounced big-endian.

> > Those two problems should be fixed instead of
> > making "hacks" to work around those, and instead
> > of blaming the use of numbers for months.

> All formats that use numbers for months are ambiguous
> and problematic, inherently.

Not in a given locale.

> > There's nothing wrong with 01.02.2013

> January second, 2013?

> > or 2013-02-01;

> This works only because nobody ever actually
> says the date that way anywhere in the world,

Wikipedia says otherwise. According the them, China/Japan/Korea
use nothing else.

> so it's obviously contrived for computer purposes
> (to make sorting work without the sort routine
> having to parse dates), and thus obviously the
> largest units are first, so it's year-month-day.

Except that internally, you'll probably not use that format,
since while it does support ordering, it doesn't help when you
need to calculate the difference between dates. Almost all
internal formats I've seen are based on the number of days since
a specific "epoch" (maybe multiplied by some multiplier, say the
number of seconds in a day).

> That's all well and good in email headers, where
> the date is written by a computer, but you're never
> going to get humans to naturally and consistently
> remember to write the date that way, because it
> doesn't match the order anyone uses when they
> say the date.

But humans fill in forms. Today, there's usually a pull down
menu for the month, so you can't get it wrong.

> Humans only use the numbers as shorthand
> for what they actually mean, so they write
> them in whatever order matches the order
> they use when they say the date -- which
> depends on their native language.

Except that the written form doesn't necessarily match the
spoken form.

[...]

> > Here again, your "advantage" is only one in the
> > context of a badly designed programming language.

> Well, yes. My preferred way to handle dates is
> to let DateTime::Format::Foo handle them for me.
> But this is C we're talking about. It doesn't have
> things like that.

The usual way to format dates in C is strftime. Which offers
about every imaginable formatting option, including locale
specific formatting. (And also suffers from the usual
C problems of requiring the client to provide a sufficiently
sized buffer---at least it also takes the size of the buffer,
and won't overwrite beyond the end. And tells you if the buffer
wasn't big enough, so you can retry with a bigger one.)

--
James

[rpresser]

On Friday, January 4, 2013 4:45:17 AM UTC-5, James wrote:

> "January tenth", but I'd write it "10 January".) For whatever
> reasons, little endian seems almost universal for dates outside
> the computer world, with the US the only exception. The choice

I have tried many times to investigate WHY and WHEN the US departed
from the "little endian" European standard. I have always come up
blank. Even up through World War I there is clear evidence in books
and letters that Americans sometimes wrote "5 June" and sometimes
"June 5". It may be that the "June 5" tradition solidified only
during the great expansion of US government during the 20th century.
I've also got a notion that the leaning to "June 5" comes from the
beginning of the US Declaration of Independence: "In Congress, July
4, 1776." -- a much beloved US document. The all numerical date
formats were not much used anywhere until the 20th century, either,
it seems.

[Janis Papanagnou]

On 04.01.2013 03:21, rpresser wrote:
> On Thursday, January 3, 2013 3:03:01 PM UTC-5, Janis wrote:
>
>> PS: Frankly, I get tired talking with citizens of the USA about
>> sensible standards; time and date, SI units, etc. So I hope we
>> have all said and can abstain from extending on that [off-]topic.
>
> Admitted bigotry.

It's interesting to hear the accusation of 'bigotry' in the context
of criticising the (in several cases!) bigotry of decisions of that
country.

Thanks for your contribution.

Janis

[Janis Papanagnou]

On 04.01.2013 11:04, James wrote:
> On Thursday, 3 January 2013 19:45:38 UTC, Jonadab the Unsightly One wrote:
>> On Jan 3, 1:11 am, Janis Papanagnou <janis_papanag...@hotmail.com>
>> wrote:

>>>> [BASIC]
>
>>> First; which "BASIC",
>
>> [...]

>
>>> Then I recall that the first string types had just a 8
>>> bit byte field to allow strings only of lengths up to
>>> only 255 characters.

(Another one, the one mentioned below, had a limit of 1023.)

>
>> I don't think I ever worked with a BASIC that had these
>> limitations. More to the point, even in the old
>> line-number BASICs you could insert things into the
>> middle of a string without worrying about overflowing
>> the allocated memory. That would be a problem in C.
>
> I've never seen a Basic which allowed insertion, or modifying

> a string in any way. [...]

The BASIC (compiler!) that had been shipped with the Olivetti
P6060 had a string module which supported replacements in
strings.

>
>> Of course, modern languages all have regex-based
>> substitution operations, so strings *have* to be
>> dynamic.
>
> I don't think so. C++ makes this mistake, but in Java, String
> objects are immutable (as they should be).

Simula also; it has TEXT objects which are descriptors to the
actual text(-array) constants.

Janis

[Janis Papanagnou]

On 04.01.2013 10:45, James wrote:
> On Thursday, 3 January 2013 06:11:07 UTC, Janis wrote:

>> [0-based arrays]
>
> [...] I can think of a lot of worse

> things in C. If you include the libraries, there's always
> gets. But the absense of a true boolean would be significant as
> well. And more generally, the syntax itself, and the large
> amount of undefined behavior. And the broken arrays.

And the inconsistent operator precedence. And non-portable basic
types. And... - Yes, there are a lot. (I am aware of those, but
in conjunction with the month mapping we talked about those other
issues seemed not relevant to note.)

>
> [...] (Developed with teletypes in mind?

> Where every character output causes a loud noise.)

:-)

>
> [...] The choice

> of big endian for the ISO date standard is probably motivated by
> the desire for trivial machine sorting (and perhaps by not
> wanting to use any existing cultural format, so as not to seem
> to be favoring that culture, or to be anti some other culture).

The else-thread posted quotes don't seem to indicate that machine
sorting would have been the motivation - quite certainly not the
primary motivation. I doubt that they wanted to avoid an existing
cultural formats; the ISO standard date is used in China which
contributes a significant population (see the Wiki map that I
posted upthread). As the standard has been defined it seems that
consistency was the primary concern.

Janis

[Janis Papanagnou]

On 04.01.2013 03:17, rpresser wrote:
> On Thursday, January 3, 2013 4:32:03 PM UTC-5, Janis wrote:
>
> [snip entire discussion on formats and sanity]
>
> Janis, if you say in one message "some formats are insane, but not
> others", then qualify it by saying "what I mean is, some formats are
> far easier to understand TODAY because they are widely used", then
> use of the word insane is just inflammatory.

I think that the term, as I used it, is completely appropriate in
the given context.

My apologies to you (and anyone else who feels that way) in case
you have been offended by that.

>
> Date formats are conventions agreed upon by people. There are
> reasons why some formats are preferred, and unreasonable accidents
> of history why other formats are preferred elsewhere. To call any of

> them insane is just being bigoted. [...]

(You said that already elsethread, and I am not the least astonished
that you, as a presumes USA citizen, choose to call others bigoted.)
Please, for a moment, take a step back and observe the international
behaviour of the US WRT international standards, international
cooperation, and global (human/civilisation) goals; there you find
pure bigotry. A lot of problems arose of that US bigotry. The ones
mentioned here are peanuts.

But note; I was neither targeting on the people, nor the government,
or the culture. I was speaking about sane definitions suitable for
international use, collaboration, and communication.

Janis

[Patric Mueller]

Janis Papanagnou <janis_pa...@hotmail.com> wrote:
> On 03.01.2013 10:56, Patric Mueller wrote:
>> Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>>> On 03.01.2013 05:35, Jonadab the Unsightly One wrote:
>>>
>>>> and are tied to
>>>> specific cultures. Date representations that use only
>>>> numbers are absolutely *horrific* in that regard.
>>>
>>> That perception must be a result of the specific cultural
>>> background as well. :-)
>>
>> The cultural background is probably being a programmer.
>
> I am not sure about that. Being a programmer and having the task to
> manipulate dates certainly will make ISO 8601 look the preferred
> representation. But even if you're a normal (non-programmer) human
> being; it's confusing if you read something like "11/10/12"! - What
> is that supposed to be?

Yes, but it is only confusing. Often you can deduce the correct date
from context. So it's often just an annoyance.

As a programmer, the problem can be much harder and you are much more
often confronted with this problem. What should be simple (after all,
a date is just a number) gets hard because of all this
inconsistencies.

> That problem is getting apparent once when
> people of different cultures talk to each other - and this is not
> an uncommon situation nowadays, to say the least.

I think the problems is much more apparent in writing. When people are
talking to each other it is much less of a problem. Especially as
usually the month is spelled out instead of using a number. Can you
even use a number for the month in English like we do in German?

>>> While I've grown up in a region where "12. Jan. 2013" was
>>> the cultural standard, I have no problems with either of
>>> 12.02.2013 or 2013-02-12.
>>
>> Of these three date representation, 1 is highly confusable, 2 are how
>> humans use dates "naturally" somewhere, and 1 is parsable but strange
>> to humans.
>
> (You have listed "1" two times; please clarify what you meant.)

12.02.2013 is confusing. 2013-02-12 looks strange for most people.

> Personally I think none of the three is "strange to humans". The
> "problem" with the first one is that interaction of people from
> different cultures is not that easy since the written month names
> will follow a language you may not be familiar with. (The same is
> true WRT the names of days in a week; shall people be supposed to
> know that "Mon" and "Lun" are the same? Could it be that in some
> language there are even name clashes, so that you associate a
> different wrong week day, or a different [abbreviated] month.)

Yes, although usually this is not a problem. If you can't decipher the
month names then of what use will be the rest of the text that most
probably will be in the same language as the month names?

>> If I really need a "normal" formatted date for human consumption, I
>> use "3. Jan 2013". I never write the month as number because that is
>> too ambiguous. Writing the month either abbreviated or not takes that
>> problem away. Even if it is localized it is recognized as month.
>
> It's recognisable as month, but in trans-national communication you
> can't expect to know what that date means; then it's not unambiguous,
> and then you need effort, further assumptions, or additional available
> meta-information to know how to translate that.
>
> That's why I (try to) always use non-abbreviated forms of ISO dates
> in global communication, e.g. if I am posting in Usenet.

In a global communication you should use the lingua franca used in the
target community (usually English).

[Janis Papanagnou]

On 04.01.2013 22:46, Patric Mueller wrote:
> Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>> On 03.01.2013 10:56, Patric Mueller wrote:
>>> Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>>>> On 03.01.2013 05:35, Jonadab the Unsightly One wrote:
>>>>
>>>> While I've grown up in a region where "12. Jan. 2013" was
>>>> the cultural standard, I have no problems with either of
>>>> 12.02.2013 or 2013-02-12.
>>>
>>> Of these three date representation, 1 is highly confusable, 2 are how
>>> humans use dates "naturally" somewhere, and 1 is parsable but strange
>>> to humans.
>>
>> (You have listed "1" two times; please clarify what you meant.)
>
> 12.02.2013 is confusing. 2013-02-12 looks strange for most people.

I don't know where you're coming from. The first one seems to be the
date ordering of most countries worldwide. The second one is used
by a lot of people worldwide and it's regular (personally I also have
no problems with it despite it's not the native format of my country).
How can those be strange[*] or confusing[**]?

[*] Outside the own nationality and culture a lot seems "strange".

[**] Can there be anything more confusing than "Fri 4. Jan 23:28:02
CET 2013"? ;-)

>
>> Personally I think none of the three is "strange to humans". The
>> "problem" with the first one is that interaction of people from
>> different cultures is not that easy since the written month names
>> will follow a language you may not be familiar with. (The same is
>> true WRT the names of days in a week; shall people be supposed to
>> know that "Mon" and "Lun" are the same? Could it be that in some
>> language there are even name clashes, so that you associate a
>> different wrong week day, or a different [abbreviated] month.)
>
> Yes, although usually this is not a problem. If you can't decipher the
> month names then of what use will be the rest of the text that most
> probably will be in the same language as the month names?

If you can't imagine it it doesn't mean there isn't. :-) For example;
two people from different countries talk in a common communication
language, and, due to being used to own national conventions, they
write a date according to their own convention; I have observed it,
it happens. Not understanding the meaning is a nuisance but can be
fixed by asking. But a misinterpretation because of name clashes
(as mentioned above) can be a problem. But while it can happen, it
can also be avoided; one way is that the parties use the month name
abbreviations of the communication language (if known), another
option is to use standard representations. The whole point is that
"bigoted" (term borrowed from rpresser) folks ignore that their own
culture is just one of many, and national cultural conventions unsuited
for international communication. My plea is not for giving up any
cultural identity, rather using international conventions if it comes
to international communication.

>
>>> If I really need a "normal" formatted date for human consumption, I
>>> use "3. Jan 2013". I never write the month as number because that is
>>> too ambiguous. Writing the month either abbreviated or not takes that
>>> problem away. Even if it is localized it is recognized as month.
>>
>> It's recognisable as month, but in trans-national communication you
>> can't expect to know what that date means; then it's not unambiguous,
>> and then you need effort, further assumptions, or additional available
>> meta-information to know how to translate that.
>>
>> That's why I (try to) always use non-abbreviated forms of ISO dates
>> in global communication, e.g. if I am posting in Usenet.
>
> In a global communication you should use the lingua franca used in the
> target community (usually English).

We do speak English here. And shall we use the date format of the
United Kingdom, DD/MM/YYYY, or DD Monthname YYYY? - The former has
the problem that it may be confused by the US-centric MM/DD/YYYY.
So are you suggesting to use the latter?

Janis

[jim in austin]

I'm not sure I would characterize us as bigots in this regard. You should remember we spent much of our history isolated from the rest of the world. It was only the World Wars that finally dragged us, reluctantly, into any sort of real engagement. Even with that we continued to follow a different drummer on standards. We still use miles, inches, yards, rods, acres, gallons, quarts, pints, teaspoons, tablespoons, ounces, pounds, tons et al. Is it any wonder we have a weird date format as well? In fact many Americans take a perverse pride in that we buck the trend and refuse to fall in line with the rest of the civilized world. I guess that's part of the price of doing business with us...

[Janis Papanagnou]

On 05.01.2013 00:56, jim in austin wrote:
> I'm not sure I would characterize us as bigots in this regard. You should
> remember we spent much of our history isolated from the rest of the world.

But note that Europe, with all their many more or less small countries, had
also different measures and units in the past, and was far from standard.
We had not only the "pound" (as weight), we had dozens different "pounds",
ranging (as far as memory serves) from ~300g to ~600g. Even across villages
and towns it was not consistent. In Germany it had been consistently defined
not before around 1850, and I'm quite sure that there were still many other
countries who followed even later. The problem with Europe was that there
had been *many* countries to agree on some consistent measures and on scales.
This, I'd have expected, could have been easier achieved and enforced if you
have a single government in a union of states like the US of America, alas,
this seems not to be the case; SI measure are standard even in the USA, since
the 1970's IIRC, but not accepted by the people in common life. In Europe
many states have given up their own convention to join a common convention;
this was a tough job, and I really wonder how that task had been achieved.
But probably the close trade interactions and collaborations made it just
necessary to agree on some convention; it is expensive to have different
units and measures. Maybe the isolation of the USA, as you pointed out, was
more a hindrance than a chance to enforce a change. As one of the main and
an important global player I wonder how the USA can still afford it to keep
its own isolated way. But, OTOH, even in Europe there's still conservative
countries who keep their traditional units. But on the whole we're moving.

> It was only the World Wars that finally dragged us, reluctantly, into any
> sort of real engagement. Even with that we continued to follow a different
> drummer on standards. We still use miles, inches, yards, rods, acres,
> gallons, quarts, pints, teaspoons, tablespoons, ounces, pounds, tons et al.

And those units have still their even global(!) relevance; aviation, pipes,
tires, oil, etc., despite most countries worldwide have agreed on SI units.

In the past we had miles as well in Europe, and again, many different values
depending on the location. WRT pints, there even seem to be different values
in the US compared to the UK - anyway, as Bavarian, I prefer the Maß (which
is about an US pint *plus* an UK pint all in one glass, the Maßkrug. ;-).

> Is it any wonder we have a weird date format as well?

Well, that depends on the people, and on the government. In our global world,
that is lead also by the USA, I still wonder about that grade of conservatism.
Specifically in trade and science, but also in communication and IT, it's
just expensive to foster not only traduced, but also inconsistent measures
and conventions. People hereabouts seem to have less problems unifying such
elementary interaction issues.

> In fact many
> Americans take a perverse pride in that we buck the trend and refuse to
> fall in line with the rest of the civilized world.

Well, but *that* is bigotry. :-)

> I guess that's part of the price of doing business with us...

It was and is expensive, not only for the business partners, also for the USA.

Janis

[jim in austin]

There was a serious federal attempt in the 1970's at "metrication". A total flop with a huge popular and political push-back. Dan Aykroyd's Saturday Night Live skit on "The Decabet: the metric alphabet" is perhaps the best example of the derision with which the attempt was met. The only remaining residue of the effort in my daily life are tiny metric equivalents in parentheses for weight and volume on packaging and the faint kph numbers on the periphery of my speedometer. It should be noted however that all science, medicine, engineering, aviation etc. have long been metric here. It is popular culture that clings to the US customary units... and they vote their convictions.

[Jorgen Grahn]

On Thu, 2013-01-03, Janis Papanagnou wrote:

[long thread on a hopeless issue]

> "11/10/12" is not ambiguous?! - Certainly it is! And this has
> nothing to do with countries writing the same date as "10/11/12",
> which is *also* an ambiguous representation.

Side note: one of my hobbies is spotting new date formats. At least
once a year I find a completely new one. One entered a source code
comment at work in December -- I think it was 05-01-2013 or something
like that.

People are inventive -- and not very interested in communicating
clearly.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Capt. Cave Man]

On 5 Jan 2013 12:45:58 GMT, Jorgen Grahn <grahn...@snipabacken.se>
wrote:

>On Thu, 2013-01-03, Janis Papanagnou wrote:
>
>[long thread on a hopeless issue]
>
>> "11/10/12" is not ambiguous?! - Certainly it is! And this has
>> nothing to do with countries writing the same date as "10/11/12",
>> which is *also* an ambiguous representation.
>
>Side note: one of my hobbies is spotting new date formats. At least
>once a year I find a completely new one. One entered a source code
>comment at work in December -- I think it was 05-01-2013 or something
>like that.
>
>People are inventive -- and not very interested in communicating
>clearly.
>
>/Jorgen

This is one element which *should be* part of a company's policy, and
ALL new hires must conform.

One certainly gets more favorable responses from gov contractors if the
entire organization uses their preferred date formatting.

Companies used to be sure to put such policies in place. Nowadays, the
folks operating companies are too stupid to understand the importance of
such "trivial" details.

[ais523]

Jorgen Grahn wrote:
> Side note: one of my hobbies is spotting new date formats. At least
> once a year I find a completely new one. One entered a source code
> comment at work in December -- I think it was 05-01-2013 or something
> like that.

/dev/null/nethack is pretty infamous for this:

<ais523> &time
<oracle\devnull> The time remaining until the 2013 Tournament
begins is '00-09-26:08-24-05'

--
ais523

[Jonadab the Unsightly One]

On Jan 4, 4:45 am, James <james.ka...@gmail.com> wrote:

> The Basics I remember only allowed two character variable
> names, the first of which had to be a letter (case
> insensitive), and the second (if present) a digit.

AppleSoft BASIC was almost that bad. (IIRC, the second
character could be a digit or a letter. Letters in
variable names were not case sensitive, however. In fact,
I don't think they were even case preserving.)

GWBASIC was considerably better, and RealBasic and later
QuickBasic and QBasic and others (APBasic, TSR Basic, etc.)
made further improvements.

And then I discovered Perl and lost interest in BASIC.

> (That's right: a maximum of 286 variables.) And the type
> was defined by a posfixed $ or some such.

We were talking about strings. *Most* languages have
different constraints on variable names versus strings.
Trivial example: almost all languages allow whitespace in
strings but relatively few languages allow whitespace in
variable names. (Perl is an example of a language that
does allow whitespace in variable names, but fortunately
the syntax you need to actually use such variables is
complicated enough that it's not done very much. In fact,
I'm not sure but what use strict might make it impossible.)

> Also no looping constructs other than a very limited for,

I think you're forgetting GOTO.

> no blocks for if (so you had to use goto), no parameters
> for functions, etc., etc.

Function parameters were possible to emulate reasonably
well for the simple cases, but if you wanted to do
recursion it was a royal pain.

> Given all that, who's worrying about string handling?

String handling was a major strength of the language.

> Many of these issues are understandable *if* you know the
> history of C, and are familiar with B (from which it
> came);

IMO, many of these things are understandable if you just
know how *old* C is. The only older language I know about
that gets most of this stuff right is Lisp, which at that
time was not suitable for many kinds of programming due to
performance issues.

These days, of course, such considerations have changed.

> There are different degrees of arbitrariness. One would
> expect either big-endian or little-endian,

I've yet to meet anyone who is not some kind of IT
professional and yet understands the concept of
endianness even when it is explained.

> But the date format we're complaining about is:
>
> Fri Jan 4 09:31:55 GMT 2013
>
> In other words: weekday month day time timezone year.
> Even growing up in America, I don't recall anyone
> inserting the time between the month/day and the year.

No, granted, normally the time would be either before the
date or after the date.

> (Curiously, in the UK, I might say "January tenth", but
> I'd write it "10 January".)

I was under the impression that they said "the tenth of
January". They certainly used to. Heck, *we* used to say
it that way in America, but we changed over to "January
tenth" some time in the nineteenth century, as part of a
general trend (which is still ongoing) toward more noun
clauses and fewer genitives.

[Jonadab the Unsightly One]

On Jan 4, 5:04 am, James <james.ka...@gmail.com> wrote:
> On Thursday, 3 January 2013 19:45:38 UTC, Jonadab the Unsightly One wrote:
>
> > I don't think I ever worked with a BASIC that had these
> > limitations. More to the point, even in the old
> > line-number BASICs you could insert things into the
> > middle of a string without worrying about overflowing
> > the allocated memory. That would be a problem in C.
>
> I've never seen a Basic which allowed insertion, or
> modifying a string in any way. The only way to change
> the value of a string variable was to assign a new string
> to it.

100 A$ = "Hello, World"
110 MID$ (A$, 8, 0) = "String Modification "
120 PRINT A$
RUN
Hello, String Modification World

> And I think your point is not that you cannot overflow
> memory; try to build a long enough string, and you will.
> The point is that the language will automatically grow or
> shrink the memory used, and will generate a defined error
> condition if the memory is exhausted.

Yes.

> > Of course, modern languages all have regex-based
> > substitution operations, so strings *have* to be
> > dynamic.
>
> I don't think so. C++ makes this mistake, but in Java,
> String objects are immutable (as they should be).

I don't consider either of those to be modern. (Java is
technically newer than Perl, but its design reflects a very
much older, more C-like style of thinking.)

> > > And don't ask for multi- byte characters or similar.
> > Multi-byte character support is newer even than Perl.
> > (Perl has full-blown Unicode support now, of course,
> > but it didn't in the early days, because nothing did
> > back then. Even the early versions of Perl5 had only
> > experimental Unicode support; it wasn't really solid
> > until I think 5.6 or so IIRC.)
>
> Multi-byte characters are far older than Unicode.

Okay, let me rephrase my statement slightly:

Embedding multi-byte characters in the same string with
plain old single-byte ASCII characters is newer even than
Perl, at least in terms of widespread adoption.

(Yes, obscure things like ZSCII did something kind of sort
of almost similar, but it was never mainstream practice
until Unicode became popular.)

[Jonadab the Unsightly One]

On Jan 4, 5:04 am, James <james.ka...@gmail.com> wrote:
> On Thursday, 3 January 2013 19:45:38 UTC, Jonadab the Unsightly One wrote:
>
> > I don't think I ever worked with a BASIC that had these
> > limitations. More to the point, even in the old
> > line-number BASICs you could insert things into the
> > middle of a string without worrying about overflowing
> > the allocated memory. That would be a problem in C.
>
> I've never seen a Basic which allowed insertion, or
> modifying a string in any way. The only way to change
> the value of a string variable was to assign a new string
> to it.

100 A$ = "Hello, World."

110 MID$ (A$, 8, 0) = "String Modification "
120 PRINT A$
RUN

Hello, String Modification World.

At one point I had plans to use strings to implement
lossless large-number arithmetic, using loops that iterate
backwards over the length of the strings and modify them in
place as needed, but I never got around to writing the
GOSUB routine for multiplication. (Addition is trivial.)

On Jan 4, 5:13 am, James <james.ka...@gmail.com> wrote:
>
> It's a difficult problem. One could argue that "1" is
> always January, where as "Jan" is locale dependent.

Except that "1" can also represent the first day of any
month.

> But since there will almost certainly be other locale
> dependent elements in any output (labels, etc.), you
> *are* outputting to a specific locale.

Date formats *have* to be for a specific locale (or, at
least, for a specific set of locales), if they are intended
to be human-readable.

> On the other hand, with the exception of the US, every
> locale has a specific order for dates, that you can count
> on: if the labels are in French or German, 1/2/2013 isn't
> ambiguous.

It's not ambiguous in the US either. 1/2/12 is January
second, nn12, where nn must be inferred from context
(usually, it refers to the most recent such year at the
time of writing, unless context clearly indicates something
else). A lot of people starting writing four-digit years
around 1999, so that would now be 1/2/2012, but I suspect
the four-digit year will be a lot less universal once
people who don't remember 1999 get out of school and into
the workplace, which will not be very much longer.

It's only when you start involving *multiple* locales that
you have a problem -- and a very big problem it can be.

> Nor is it ambiguous if the labels use British spelling in
> English (but they might not contain a word where the
> spelling is different).

Also, people aren't always cognizant of the differences
between British and American English, or the other
country's version may just be seen as "old fashioned" or
whimsical and may occur in some contexts e.g. to add
historical flavor.

Also, many Americans are completely unaware that people
write short dates in a different order elsewhere in the
world.

[Jonadab the Unsightly One]

On Jan 4, 5:34 am, James <james.ka...@gmail.com> wrote:
> Note that if the US were some small country using a
> language that no one else used, we wouldn't care about
> it.

There's also the small fact that the software industry was
invented here. (Jacquard was European, sure; but he was
pretty far ahead of his time, and so nobody really thought
to build an industry on his work.) Actually, most other
countries didn't have much of a software industry until
quite recently. (Germany and England are both exceptions
to this, having gotten involved pretty early. There are
several others as well. But they are exceptions.)

> Dates are locale specific, and would be unambigous in the
> given locale.

Yes. I maybe wasn't clear, but I meant to imply this.

> It's the widespread use of English, and the fact that
> many English speaking locales use the DMY format which
> causes the problem.

Okay, yeah, the American and British locales are in most
respects so similar that it is fairly unimportant to bother
producing separate localized versions of most software,
provided you can deal with the short date issue; which you
often can, by checking the OS settings for date format
(rather than naively hardcoding it in the localized build
of the application).

> > All formats that use numbers for months are ambiguous
> > and problematic, inherently.
>
> Not in a given locale.

Granted.

> > That's all well and good in email headers, where the
> > date is written by a computer, but you're never going
> > to get humans to naturally and consistently remember to
> > write the date that way, because it doesn't match the
> > order anyone uses when they say the date.
>
> But humans fill in forms. Today, there's usually a pull
> down menu for the month, so you can't get it wrong.

Yes, that works nicely.

[Jonadab the Unsightly One]

On Jan 4, 11:36 am, rpresser <rpres...@gmail.com> wrote:
> On Friday, January 4, 2013 4:45:17 AM UTC-5, James wrote:
> > "January tenth", but I'd write it "10 January".)

Why would spelling the number out versus writing it in
digits make any difference for the order? To an American,
this seems far stranger than any particular order would be
if used consistently.

> I have tried many times to investigate WHY and WHEN the
> US departed from the "little endian" European standard. I
> have always come up blank. Even up through World War I
> there is clear evidence in books and letters that
> Americans sometimes wrote "5 June" and sometimes "June
> 5". It may be that the "June 5" tradition solidified only
> during the great expansion of US government during the
> 20th century. I've also got a notion that the leaning to
> "June 5" comes from the beginning of the US Declaration
> of Independence: "In Congress, July 4, 1776." -- a much
> beloved US document. The all numerical date formats were
> not much used anywhere until the 20th century, either, it
> seems.

I strongly suspect it's part of a larger linguistic trend
away from genitives ("A of B of C") and toward more and
longer noun phrases ("C B A"), a trend that was already
underway in the 1800s but has observably proceeded further
even within the last thirty years or so.

[Jonadab the Unsightly One]

On Jan 5, 6:56 am, jim in austin <jimeik...@gmail.com> wrote:

> There was a serious federal attempt in the 1970's at
> "metrication". A total flop with a huge popular and
> political push-back.

It lasted into the eighties, with elementary schools all
trying to "teach metric", but fortunately they went about
it all wrong and none of the kids learned much of it.

They tried to teach conversion factors for every unit:
the number of cm in an inch, yards in a meter, miles in a
kilometer, grams in an ounce, and so on and so forth. Plus
we still had to learn all the traditional ones, like how
many yards there are in a mile (because THAT is definitely
important to know, in the eye of a daft insane pig), cups
in a peck (yeah, I use that one pretty much daily), and so
on. There must have been two hundred different conversion
factors they tried to cram into our brains, entirely by
rote. I remember about two dozen of them. The only one I
*don't* remember that I would potentially use if I did know
it is the number of tablespoons in a cup. (Ones I both
remember and use include teaspoons to tablespoons, cups to
pints to quarts to gallons, and inches to feet, all of
which are easy, partly because they are small numbers and
partly because there are everyday household objects
associated with every one of these measurements. I also
remember the numbers for feet-to-yards-to-miles, but I
cannot imagine ever having a real use for them. Yards are
only ever used in football, and miles are at such a larger
scale than feet that the idea of converting between them is
fundamentally ludicrous.) They also tried to teach us
about thirty different metric prefixes, most of which were
completely pointless. (Ironically, the computer industry
has since familiarized everyone quite thoroughly with mega-
and giga-, formerly two of the completely worthless ones.
But we still don't need to remember which is which between
deci and deca, although I now can thanks to having studied
certain dead languages for unrelated reasons; and I have
always had an easy time remembering hecto-, although I
have never once seen it actually used.)

High school and college science classes use SI extensively,
so most well-educated Americans are familiar with the gram,
the meter, and the prefixes kilo- and milli- and centi-.
Also, pop is commonly sold in two-litre bottles, so we have
a fair idea how much a litre is from that. (Otherwise we
wouldn't; science classes usually just use cubic meters or
cubic centimeters for volume.)

Don't ask an American how far a kilometer is, though,
unless you want "a thousand meters" as your answer. We can
never remember whether it's more or less than a mile, and
we only have a pretty vague idea how far a mile is anyway.
(We measure travel distances in minutes and hours.)

[Janis Papanagnou]

On 06.01.2013 01:35, Jonadab the Unsightly One wrote:
> On Jan 4, 5:04 am, James <james.ka...@gmail.com> wrote:
>
>>>> And don't ask for multi- byte characters or similar.
>>> Multi-byte character support is newer even than Perl.
>>> (Perl has full-blown Unicode support now, of course,
>>> but it didn't in the early days, because nothing did
>>> back then. Even the early versions of Perl5 had only
>>> experimental Unicode support; it wasn't really solid
>>> until I think 5.6 or so IIRC.)
>>
>> Multi-byte characters are far older than Unicode.
>
> Okay, let me rephrase my statement slightly:
>
> Embedding multi-byte characters in the same string with
> plain old single-byte ASCII characters is newer even than
> Perl, at least in terms of widespread adoption.

Where is such a mix done? - Mind that ASCII being a subset
of e.g. ISO 8859-x character sets and a subset of the UTF-8
encoding does not mean that it's a mix; it's an extension
with clearly defined and unambiguous semantics. Typically
you find either explicitly defined or implicitly presumed
contexts of the underlying character set. One could never
separate "mixes" of character sets in the general case. -
Where have you found such (untagged/unqualified) mixes?

>
>> But since there will almost certainly be other locale
>> dependent elements in any output (labels, etc.), you
>> *are* outputting to a specific locale.
>
> Date formats *have* to be for a specific locale (or, at
> least, for a specific set of locales), if they are intended
> to be human-readable.

There are date formats that are used by many countries, and
there are countries that support more than one format. So
considering this, it makes limited sense to tightly couple
it to locales.

Janis

[Janis Papanagnou]

My spontaneous guess would be: 9 months, 26 days, 8 hours, 24 minutes,
and 5 seconds. (Assuming a regular ordering.)

One of the ISO defined formats for periods would not be very different:
P0000-09-26T08:24:05, only other delimiters and a fully specified year.
(Another ISO convention for the same period is P9M26DT8H24M5S.)

Janis

[Janis Papanagnou]

I think that it's getting worse and worse; "nine eleven",
mind! Is that supposed to be a date, even in colloquial
speech? (Obviously it is, but should that, in the opinion
of an US citizen, be the evolutionary route that the US
American language should take?)

In many countries there are institutes or organisations
that strive to keep a language intact on a high linguistic
level, to avoid the decay and decadence of their language.
Is there something like that in the US? (I'd suppose so;
but if that's the case they're doing a fairly bad job.)

Janis

[jerk-o]

On Sat, 5 Jan 2013 17:37:37 -0800 (PST), Jonadab the Unsightly One
<jonadab.the...@gmail.com> wrote

>Don't ask an American how far a kilometer is, though,
>unless you want "a thousand meters" as your answer. We can
>never remember whether it's more or less than a mile, and
>we only have a pretty vague idea how far a mile is anyway.
>(We measure travel distances in minutes and hours.)

A kilometer is roughly 0.6 miles.
--
no, i didn't forget the 'F's
http://www.youtube.com/watch?v=DZ7dPCH_gW0

[jim in austin]

On Saturday, January 5, 2013 9:25:28 PM UTC-6, Janis wrote:
> In many countries there are institutes or organisations
> that strive to keep a language intact on a high linguistic
> level, to avoid the decay and decadence of their language.
> Is there something like that in the US? (I'd suppose so;
> but if that's the case they're doing a fairly bad job.)

Absolutely not. English may be one of the most dynamic and ever-changing languages in recorded history. It is totally eclectic. Every year the dictionaries scramble to list all of the new words, phrases and expressions that have come into popular usage. Slang, new constructs and foreign adoptions are the norm. There are patois that I can barely understand but they are no less English than what I speak. The language is total anarchy and that is perhaps why it is considered so creative and expressive...

[Doug Freyburger]

Jonadab the Unsightly One wrote:

> jim in austin <jimeik...@gmail.com> wrote:
>
>> There was a serious federal attempt in the 1970's at
>> "metrication". A total flop with a huge popular and
>> political push-back.
>
> It lasted into the eighties, with elementary schools all
> trying to "teach metric", but fortunately they went about
> it all wrong and none of the kids learned much of it.

I lerned metric in the 1960s in elementary school. We spent about a
day learning metric. Gram, kilogram, second, centimeter, meter,
liter, a few others. Then deci/deca, centi/heca, milli/kilo,
mega/micro, giga/nano. And a book to look up more of the Greek words for
other more extreme prefixes. They showed us a meter stick karked off in
10, 100 and 1000 marks. That's decimeters, centimeters, millimeters.
They said everything metric works like that going down. And it works
the same way going up once you memorize the other Greek words. They had
us heft a kilogram and gram weight from an equal beam balance. That
was it, we were done until we got to physics and all of those electric
units came in.

Then we started months of that other system. Something about milk
coming in floz but flour coming in nitwit oz. I memorized enough of
those obscure numbers to get along. I never got the point once I knew
how metric worked. Sixteen floz to the pint but there's like twelve
sorts of ounces and floz and nitwit oz are maybe not even the two most
common ounces. Who would come up with such a system?

> High school and college science classes use SI extensively,
> so most well-educated Americans are familiar with the gram,
> the meter, and the prefixes kilo- and milli- and centi-.
> Also, pop is commonly sold in two-litre bottles, so we have
> a fair idea how much a litre is from that. (Otherwise we
> wouldn't; science classes usually just use cubic meters or
> cubic centimeters for volume.)

Sodas are bizzare. 12 floz, half liter, 20 floz, 24 floz, liter, liter
and a half, two liter.

> Don't ask an American how far a kilometer is, though,
> unless you want "a thousand meters" as your answer. We can
> never remember whether it's more or less than a mile, and
> we only have a pretty vague idea how far a mile is anyway.
> (We measure travel distances in minutes and hours.)

Unless she's been in the military or taken an engineering class or
worked in a factory. I don't get why the old system still gets used at
all. Miles on signs? Whatever.

[David Damerell]

Quoting James <james...@gmail.com>:
>Insisting that all arrays have the same base is a significant
>limitation, however; more than once, I've wanted 0 to be in the
>middle of the array, with bounds `[-n...n]`
>(`[CHAR_MIN...CHAR_MAX]`, for example). _My_ vector classes in
>C++ supported this.

Perl has a (severely deprecated) feature for changing the first array
index, but more usefully takes negative array indices to count backwards
from the final element - so, with caution, one can use [-n ... n].
--
David Damerell <dame...@chiark.greenend.org.uk> flcl?
Today is First Epithumia, January - a weekend.
Tomorrow will be First Olethros, January - a weekend.

[David Damerell]

Quoting Janis Papanagnou <janis_pa...@hotmail.com>:
>On 03.01.2013 05:35, Jonadab the Unsightly One wrote:
>>[...] String length isn't even dynamic,
>>something BASIC got right way back I don't even know what
>>decade.
>I disagree. First; which "BASIC", since there were tons of
>(incomparable) variants. Then I recall that the first string

>types had just a 8 bit byte field to allow strings only of

>lengths up to only 255 characters. And don't ask for multi-
>byte characters or similar.

Also, _changing_ the length of a BASIC string tended to leak memory on
many implementations.

[David Damerell]

Quoting rpresser <rpre...@gmail.com>:
>bigotry is useful, in that it discourages use of deliberately
>ridiculous calendars:

http://www.chiark.greenend.org.uk/~damerell/birthdaycal.html

[David Damerell]

Quoting Jonadab the Unsightly One <jonadab.the...@gmail.com>:
>>no blocks for if (so you had to use goto), no parameters
>>for functions, etc., etc.
>Function parameters were possible to emulate reasonably
>well for the simple cases, but if you wanted to do
>recursion it was a royal pain.

Depends on your BASIC. BBC BASIC had function parameters - you could even
pass in pointers if you fancied it, albeit that was relatively deep magic.

[Jonadab the Unsightly One]

On Jan 5, 10:25 pm, Janis Papanagnou <janis_papanag...@hotmail.com>
wrote:

> > we changed over to "January tenth" some time
> > in the nineteenth century, as part of a general
> > trend (which is still ongoing) toward more noun
> > clauses and fewer genitives.
>
> I think that it's getting worse and worse; "nine eleven",

We usually say "nine one one".

(It happens that 911 is the standard emergency services
phone number in America, originally established in the
eighties and heavily advertised in the nineties. There was
even a popular TV show called "Rescue 911" in the 90s, all
about fires and car accidents and medical incidents and all
manner of horrific emergencies. My youngest sister used to
watch it regularly. After the September 11th incident, it
took most folks several days to get over their shock enough
to put two and two together and realize that the date of
9/11 just happened to correspond to the phone number 911,
but once this was realized it was inevitable that the date
would be pronounced that way.)

> In many countries there are institutes or organisations
> that strive to keep a language intact on a high linguistic
> level, to avoid the decay and decadence of their language.

That sounds like something France would come up with.
Simultaneously inane *and* pretentious.

> Is there something like that in the US?

If there were, Americans would just make fun of it
(if we noticed it at all).

[Jonadab the Unsightly One]

On Jan 5, 10:54 pm, jerk-o <jer...@yomomma.org> wrote:
> On Sat, 5 Jan 2013 17:37:37 -0800 (PST), Jonadab the Unsightly One

> <jonadab.theunsightly...@gmail.com> wrote

>
> >Don't ask an American how far a kilometer is, though,
> >unless you want "a thousand meters" as your answer. We can
> >never remember whether it's more or less than a mile, and
> >we only have a pretty vague idea how far a mile is anyway.
> >(We measure travel distances in minutes and hours.)
>
> A kilometer is roughly 0.6 miles.

I imagine I'll remember that fact for several hours.

[Jonadab the Unsightly One]

> I lerned metric in the 1960s in elementary school. We
> spent about a day learning metric. Gram, kilogram, second,
> centimeter, meter, liter, a few others. Then deci/deca,
> centi/heca, milli/kilo, mega/micro, giga/nano.

They drilled that junk into us 2-3 hours a week for about
six years, but they did it so ineptly that I remember well
less than a quarter of it.

Which is fine. I do know the parts that are actually
*useful*. The rest of it can go suck an egg. I don't
care how many picoliters there are in a yottoliter. It's
not something I will ever need to know. Knowing it would
not enhance my understanding of anything in any way.

> And a book to look up more of the Greek words for other
> more extreme prefixes.

The extreme prefixes are largely pointless.

Okay, sure, if you work in the semiconductor industry you'll
probably learn nano- and use it on a regular basis.
Compared to all the other junk you have to learn to work in
the semiconductor industry, that's small potatoes. There's
no reason for the rest of us to learn it.

> They showed us a meter stick karked off in 10, 100 and
> 1000 marks. That's decimeters, centimeters, millimeters.

As a kid, I could never keep deci straight from deca.

> Then we started months of that other system. Something
> about milk coming in floz but flour coming in nitwit oz.
> I memorized enough of those obscure numbers to get along.
> I never got the point once I knew how metric worked.
> Sixteen floz to the pint but there's like twelve sorts of
> ounces and floz and nitwit oz are maybe not even the two
> most common ounces. Who would come up with such a system?

Unless you're in the jewelry industry, there are only two
kinds of ounces you need to know about. When talking about
weight (or force, I suppose, but if you're calling weight a
"force" you're probably in physics class and measuring it in
newtons), an ounce is a sixteenth of a pound.

The other kind of ounce that anyone actually uses is a fluid
ounce, and there are eight of them in a cup. (From there,
there are two cups in a pint, two pints in a quart, and four
quarts in a gallon, all of which are extremely easy to
remember because we have everyday household containers in
all of those sizes. If you set a pint jar and a quart jar
beside one another, it's pretty obvious that the one is
about twice as large as the other.)

> > High school and college science classes use SI
> > extensively, so most well-educated Americans are
> > familiar with the gram, the meter, and the prefixes
> > kilo- and milli- and centi-. Also, pop is commonly sold
> > in two-litre bottles, so we have a fair idea how much a
> > litre is from that. (Otherwise we wouldn't; science
> > classes usually just use cubic meters or cubic
> > centimeters for volume.)
>
> Sodas are bizzare. 12 floz, half liter, 20 floz, 24 floz,
> liter, liter and a half, two liter.

I've never seen a half-liter anything.

Old-fashioned glass pop bottles used to be a quart in most
of the US, but the ones in Michigan were a liter. The
difference in size wouldn't have been particularly
noticeable, but they were also shaped differently (shorter
and squatter; the quart ones the rest of the country used
were taller and thinner). However, I haven't seen a glass
pop bottle of any size for about two decades now.

Pop cans are 12 floz, i.e., a cup and a half, which is just
about the smallest beverage size you will ever seen in
America. (Some restaurants do have an even smaller size for
very young children, but it's almost never listed on the
menu -- you have to specifically ask about it. Airlines
also have a smaller size, probably because they're worried
about air sickness and vomit, although frequent air
travelers tend to assume more sinister motives.)

The most common beverage size at restaurants is 32 floz --
i.e., one quart. Sometimes this is the largest size
available, sometimes not (48oz and 64oz also exist), but I
don't think there's a single major fast-food chain (in
America) that doesn't have 32oz beverages. If 32oz is the
large size, the medium is typically somewhere in the range
of 20-24. (When I worked at McD's, the medium size was
21oz. Yes, that's a strange number, but the customers never
worry about how many ounces it is anyway.)

> > Don't ask an American how far a kilometer is, though,
> > unless you want "a thousand meters" as your answer. We
> > can never remember whether it's more or less than a
> > mile, and we only have a pretty vague idea how far a
> > mile is anyway. (We measure travel distances in minutes
> > and hours.)
>
> Unless she's been in the military or taken an engineering
> class or worked in a factory.

Even engineering classes don't *mix* SI with the everyday
units. You either use one or the other, depending on what
you're doing (and, in particular, whether it's anything
normal people will have to interact with on a regular
basis). There's practically never any need to convert
between them.

> I don't get why the old system still gets used at all.
> Miles on signs? Whatever.

Miles are useful on signs because automobile trip meters
show miles. Automobile trip meters show miles so people can
determine mileage (both for fuel efficiency calculations and
also for business travel expense reimbursement purposes).
A car with a km-only trip meter would be at a significant
disadvantage from a sales standpoint.

Kilometers aren't a worse unit of measurement than miles,
but they're also not significantly better, and they're not
backward-compatible. There's a reason Itanium never caught
on and x86-64 did. It's not because Itanium is inherently a
worse architecture than x86-64. It's because Itanium wasn't
backward-compatible with x86, and x86-64 was.

SI is used in situations where its advantages are actually
meaningful, e.g., in physics classrooms.

[Jonadab the Unsightly One]

On Jan 7, 12:38 pm, David Damerell <damer...@chiark.greenend.org.uk>
wrote:

> Quoting Jonadab the Unsightly One <jonadab.theunsightly...@gmail.com>:
>
> >>no blocks for if (so you had to use goto), no parameters
> >>for functions, etc., etc.
> >Function parameters were possible to emulate reasonably
> >well for the simple cases, but if you wanted to do
> >recursion it was a royal pain.
>
> Depends on your BASIC.

Granted. Most of the later BASICs (e.g., RealBasic,
QuickBasic, QBasic, APBasic) had function parameters.

> BBC BASIC had function parameters

Really? Interesting. I think that's the oldest BASIC I've
heard of that supported that.

> you could even pass in pointers if you fancied it,

Ew.

Pointers are a fundamentally bad idea for a high-level
language. Way More Trouble Than It's Worth. Much better to
have proper high-level data structures and references and
make raw pointers completely unnecessary.

[rpresser]

Growing up in southern NJ, where the area code was (at the time) 609,
it was easy to memorize this: 1 mile = 1.609 km

[David Damerell]

Quoting Jonadab the Unsightly One <jonadab.the...@gmail.com>:
>On Jan 7, 12:38 pm, David Damerell <damer...@chiark.greenend.org.uk>

>>BBC BASIC had function parameters
>Really? Interesting. I think that's the oldest BASIC I've
>heard of that supported that.

For a BASIC, it's a pretty capable language. The functions even have a
return value. :-)

>>you could even pass in pointers if you fancied it,
>Ew.

No-one's making you do it (and in practice no-one did do what I had in
mind, but there is a way to say essentially *foo = new(sizeof(int)) and
then pass foo into a function).
--
David Damerell <dame...@chiark.greenend.org.uk>
Clown shoes. I hope that doesn't bother you.
Today is First Olethros, January - a weekend.
Tomorrow will be Gaiman, January - a public holiday.

[David Damerell]

Quoting jim in austin <jime...@gmail.com>:
>It should be noted however that all science, medicine, engineering,
>aviation etc. have long been metric here.

http://en.wikipedia.org/wiki/Mars_Climate_Orbiter - you wish.

[David Damerell]

Quoting Jonadab the Unsightly One <jonadab.the...@gmail.com>:

>>And a book to look up more of the Greek words for other
>>more extreme prefixes.
>The extreme prefixes are largely pointless.

How big's your hard drive, again?

>The other kind of ounce that anyone actually uses is a fluid
>ounce, and there are eight of them in a cup.

Not forgetting a) that a British floz is slightly smaller and b) that cups
are used as a volumetric measurement of compressible substances, which is
sheer lunacy.

[Doug Freyburger]

Jonadab the Unsightly One wrote:

> Janis Papanagnou <janis_papanag...@hotmail.com> wrote:
>
>> > we changed over to "January tenth" some time
>> > in the nineteenth century, as part of a general
>> > trend (which is still ongoing) toward more noun
>> > clauses and fewer genitives.

At some point ISO switched to all numbers in sortable order so tday is
2012-01-08. I now use that format a lot, but with my pen I still tend
to use the format I learned for the US military 08 Jan 2013.

>> I think that it's getting worse and worse; "nine eleven",
>
> We usually say "nine one one".
>
> (It happens that 911 is the standard emergency services
> phone number in America, originally established in the
> eighties and heavily advertised in the nineties. There was
> even a popular TV show called "Rescue 911" in the 90s, all
> about fires and car accidents and medical incidents and all
> manner of horrific emergencies. My youngest sister used to
> watch it regularly. After the September 11th incident, it
> took most folks several days to get over their shock enough
> to put two and two together and realize that the date of
> 9/11 just happened to correspond to the phone number 911,
> but once this was realized it was inevitable that the date
> would be pronounced that way.)

So the emergency number is "nine one one" but the date is "nine eleven".
What few in the west realize is they should read a translation of Koran
Sura 9 and try various translations to see what line is most commonly
counted as Sura nine verse eleven. The date was no coinsidence. The
attack follows the directions of that verse.

Bizzarely - That's the behavior we nethack players expect from monsters.

[Doug Freyburger]

Jonadab the Unsightly One wrote:

> Doug Freyburger wrote:
>
>> I lerned metric in the 1960s in elementary school. We
>> spent about a day learning metric. Gram, kilogram, second,
>> centimeter, meter, liter, a few others. Then deci/deca,
>> centi/heca, milli/kilo, mega/micro, giga/nano.
>
> They drilled that junk into us 2-3 hours a week for about
> six years, but they did it so ineptly that I remember well
> less than a quarter of it.

Lots of people remember skills fromelementary school but no content.
This is consistent with the claim that the content of a college
technical degree goes obsolete several times in a career.

To me the skill was simple - Shift decimal places, memorize several
useful prefixes, know where to look up the other prefixes. And there
you are completely done with learning the metric system.

> Which is fine. I do know the parts that are actually
> *useful*. The rest of it can go suck an egg. I don't
> care how many picoliters there are in a yottoliter. It's
> not something I will ever need to know. Knowing it would
> not enhance my understanding of anything in any way.

Chip designers, physicists and such for the obscure small ones. IT
folks and astronomers for the obscure big ones. I've needed both but
they are obscure. Who really needs fempto- or exa-? Almost no one. As
long as you know how to look up the big list of obscure prefixes you
have all you'll ever need.

>> They showed us a meter stick karked off in 10, 100 and
>> 1000 marks. That's decimeters, centimeters, millimeters.
>
> As a kid, I could never keep deci straight from deca.

Which is why the 10 and 1/10 words never seem to get used. Check.

>> Sodas are bizzare. 12 floz, half liter, 20 floz, 24 floz,
>> liter, liter and a half, two liter.
>
> I've never seen a half-liter anything.

Coke switch from the 16 floz bottles to the half liter ones in some
vending machines. In that list it's the least common size. I never
see the 16 floz size since then.

>> Unless she's been in the military or taken an engineering
>> class or worked in a factory.
>
> Even engineering classes don't *mix* SI with the everyday
> units. You either use one or the other, depending on what
> you're doing (and, in particular, whether it's anything
> normal people will have to interact with on a regular
> basis). There's practically never any need to convert
> between them.

The only conversion I even did in engineering is CGS to MKS. Metric
starting from different sizes. Chemistry is centimeter gram second,
other fields mostly meter, kilogram second.

>> I don't get why the old system still gets used at all.
>> Miles on signs? Whatever.
>
> Miles are useful on signs because automobile trip meters
> show miles. Automobile trip meters show miles so people can
> determine mileage (both for fuel efficiency calculations and
> also for business travel expense reimbursement purposes).
> A car with a km-only trip meter would be at a significant
> disadvantage from a sales standpoint.

This is of course circular reasoning. Why don't we use metric? Because
we didn't used to use metric.

[Janis Papanagnou]

I see to recall that France as well has such institutes, indeed.

>
>> Is there something like that in the US?
>
> If there were, Americans would just make fun of it
> (if we noticed it at all).

Curious again; if there's some dictionaries, say implemented in
computers, who would define what's correct or incorrect usage?
(You know what I mean? Those red, green, blue, underlined words.)

Still can't understand why not having a language well defined
would be a considered good thing in the USA, and why having it
well defined, consistent, and reliable, a funny issue.

Hereabouts we have as well an evolving language and changes in
that language[*]. That doesn't make a language standard and
preservation of a language level or efforts to keep language
idiosyncrasies a less useful thing or less worth striving for;
rather the opposite is the case.

Janis

[*] Sadly, many changes do not the best to the language. E.g.
anglicisms flood our language, mainly through advertising and
marketing efforts. Despite having very expressive original
words and formulations[**] in our own language it degrades in
common colloquial use.

[**] Keeping language standards and fostering them is IMO also
one precondition for non-trivial literature.

[Janis Papanagnou]

Understandable if you're used to something else.

One question would be; could there be a reason to switch to
a more consistent and internationally standardised system?
The answer to that question will not only influence the ease
or difficulty to internationally cooperate with less risks
to make errors[*], but also how hard or easy descendants
of your country will be able to learn issues and relations.
It's a question of future perspective.

Janis

[*] Remember that US space probe that missed a planet!?

[Janis Papanagnou]

On 08.01.2013 15:12, Jonadab the Unsightly One wrote:
>
> The extreme prefixes are largely pointless.

If one thinks only in distance ranges from the door of ones
own house to the borders of the own country, if one thinks
only in time scales from own birth to dead, if one thinks
only in how many fluid is in ones pint of beer than how many
water is bound in Arctic ice any may destroy our environment.
Yes, then those units could be pointless.

>
> Even engineering classes don't *mix* SI with the everyday
> units.

You think it's an advantage to have two independent measures
in a country? (One locale specific and one international.)
You think it is easier to have many people in your country
learn both than just one?

Janis

[Janis Papanagnou]

On 08.01.2013 22:30, Jukka Lahtinen wrote:

> Doug Freyburger <dfre...@yahoo.com> writes:
>> Jonadab the Unsightly One wrote:
>
>>> As a kid, I could never keep deci straight from deca.
>> Which is why the 10 and 1/10 words never seem to get used. Check.
>

> Deciliter is about the only deci- or deca-unit regularly used around here.

I want to add that such prefixes are also used in languages;
say in words like decalog, decade, etc., which indicate a
scale factor of 10. So I think it could be quite easily
memorable even in countries that are historically used to
non-regular scales.

Janis

[MrTallyman]

It is also a GIGAntic error to pronounce the term Gigabyte with a hard
"G" or short "I". it should be exactly as it is pronounced in the word
gigantic.

[Benjamin A. Schmit]

2013-01-09 08:57 – Janis Papanagnou:

Where I come from, we do use the dekagram (dag) on a daily-life basis
(e.g. when buying open cheese at a store, or for cooking ingredients).
But we are well-aware that this is a local eccentricity which even
citizens of neighbouring countries mostly won't understand.

Actually, we commonly abbreviate it as "deka" in colloquial speech.
Another point against this prefix – it seems to be clear enough what is
meant even without naming the unit itself.

Benjamin


--
Seek freedom and become captive of your desires.
Seek discipline and find your liberty.
-- Frank Herbert, Dune Chronicles

[Doug Freyburger]

Janis Papanagnou wrote:
>
> One question would be; could there be a reason to switch to
> a more consistent and internationally standardised system?

International trade. It's why almost all industry in the US has been
metric for decades. And each year there's less ancient system use in
industry. Even high school sport tracks have been 400 meter stadia for
decades.The only things left on the bizzare ancient system are cosmetic
ones like road signs and soup recipes. But people grow up seeing the
cosmetic parts and don't encounter the more important ones until they
get a job in industry.

> The answer to that question will not only influence the ease
> or difficulty to internationally cooperate with less risks
> to make errors[*], but also how hard or easy descendants
> of your country will be able to learn issues and relations.
> It's a question of future perspective.

There is tourism impact. US travellers like to go abroad but there has
been the belief that since our culture is newer there's less market for
tourism into the US. Use o fth eancient bizzare system hurts any
efforts at drawing tourists from overseas.

> [*] Remember that US space probe that missed a planet!?

I figure we didn't miss the planet itself. We just haven't noticed the
crater yet. ;^)

[Jorgen Grahn]

On Wed, 2013-01-09, Benjamin A. Schmit wrote:
...

> Where I come from, we do use the dekagram (dag) on a daily-life basis
> (e.g. when buying open cheese at a store, or for cooking ingredients).
> But we are well-aware that this is a local eccentricity which even
> citizens of neighbouring countries mostly won't understand.
>
> Actually, we commonly abbreviate it as "deka" in colloquial speech.

> Another point against this prefix ??? it seems to be clear enough what is

> meant even without naming the unit itself.

Around here it's known as a "hektogram" or "hekto", for some reason.
Used almost exclusively for cooking.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[rpresser]

On Wednesday, January 9, 2013 2:28:31 AM UTC-5, Janis wrote:
> Curious again; if there's some dictionaries, say implemented in
> computers, who would define what's correct or incorrect usage?
> (You know what I mean? Those red, green, blue, underlined words.)

The writer of the program would make that decision. She would probably
base it on a well-respected commercial dictionary, such as Webster's,
American Heritage, or the OED.

> Still can't understand why not having a language well defined
> would be a considered good thing in the USA, and why having it
> well defined, consistent, and reliable, a funny issue.

It would be seen as (a) unnecessary interference and (b) arrogant
interference. And it would be resented even more if the organization
had any governmental connection. Languages should be described,
not defined. Language is an organic outgrowth of the human brain --
not something handed down by forefathers to be strictly adhered to.

This isn't just the US, by the way; sorry to disappoint you, but
there is no standard-bearer for English in any of the many countries
where it is spoken.

> [**] Keeping language standards and fostering them is IMO also
> one precondition for non-trivial literature.

Yes, certainly no non-trivial literature was ever written by Shakespeare,
Chaucer, Voltaire, Dostoevsky, or any of the other thousand writers
who wrote completely free of any language standards.

[rpresser]

On Wednesday, January 9, 2013 2:36:04 AM UTC-5, Janis wrote:
> [*] Remember that US space probe that missed a planet!?

You mean just like the Japanese space probe missed Venus in 2010?

[Janis Papanagnou]

On 10.01.2013 08:03, rpresser wrote:
> On Wednesday, January 9, 2013 2:28:31 AM UTC-5, Janis wrote:
>> Curious again; if there's some dictionaries, say implemented in
>> computers, who would define what's correct or incorrect usage?
>> (You know what I mean? Those red, green, blue, underlined words.)
>
> The writer of the program would make that decision. She would probably
> base it on a well-respected commercial dictionary, such as Webster's,
> American Heritage, or the OED.
>
>> Still can't understand why not having a language well defined
>> would be a considered good thing in the USA, and why having it
>> well defined, consistent, and reliable, a funny issue.
>
> It would be seen as (a) unnecessary interference and (b) arrogant
> interference. And it would be resented even more if the organization
> had any governmental connection.

I very well understand that point of view. Avoidance of governmental
interference is one (as I think very important!) property of the US
American socio-political cultural basis.

> Languages should be described,
> not defined. Language is an organic outgrowth of the human brain --
> not something handed down by forefathers to be strictly adhered to.

That depends on the application of the language. If you'd just speak it
[informally] "on the street" that would be a different issue than if you
want or need to rely on meaning, by well defined syntax and semantics.
So I have to disagree with what you say here.

>
> This isn't just the US, by the way; sorry to disappoint you, but

(You do not disappoint me.)

> there is no standard-bearer for English in any of the many countries
> where it is spoken.

I'd expect that this is the case in many languages and countries not
only, as it seems to be the case, in the USA. I'd think, though, that
in "better" developed countries that would more likely be an issue
than, say, in the so called Third World countries. And I've heard that
such institutes exist in quite a couple of the "First World" countries.
(To my knowledge the USA has also other institutions, e.g. to keep the
quality of food on a necessary level; that was the reason why I asked
the question WRT the language.)

>
>> [**] Keeping language standards and fostering them is IMO also
>> one precondition for non-trivial literature.
>
> Yes, certainly no non-trivial literature was ever written by Shakespeare,
> Chaucer, Voltaire, Dostoevsky, or any of the other thousand writers
> who wrote completely free of any language standards.

This provocative statement misses the point. If Shakespeare would not
have written with the given quality he would just have been forgotten.
(But nowadays there's not just a few who exchange speech and words
across the whole world. And language degrades, as we can observe; that
was and is my primary concern.)

Janis

[Janis Papanagnou]

They consistently used SI and missed, or what? Please elaborate.

The US incident WRT that Mars space probe clearly was a problem
of using and mixing non-standard units.

Janis

[Janis Papanagnou]

On 10.01.2013 08:33, Janis Papanagnou wrote:
> On 10.01.2013 08:09, rpresser wrote:
>> On Wednesday, January 9, 2013 2:36:04 AM UTC-5, Janis wrote:
>>> [*] Remember that US space probe that missed a planet!?
>>
>> You mean just like the Japanese space probe missed Venus in 2010?
>
> They consistently used SI and missed, or what? Please elaborate.

(I looked it up myself...)

Those incidents are not comparable. The Venus space probe had problems
with a communication loss and the deceleration boosters could not get
activated.

It seems not comparable to the issue we talked about:

[jim in austin]

The closest thing we have to both authoritative AND enforceable sources of enlightenment are various journalistic guides such as The New York Times Manual of Style and Usage, The Chicago Manual of Style or The Associated Press Stylebook and Briefing on Media Law. You're perfectly free to ignore them of course, but they probably won't publish your stuff. Therein lies the enforcement...

[MrTallyman]

On Thu, 10 Jan 2013 08:40:28 +0100, Janis Papanagnou
<janis_pa...@hotmail.com> wrote:

>> The US incident WRT that Mars space probe clearly was a problem
>> of using and mixing non-standard units.
>>
>> Janis
>>

It was absolutely operator error. He assumed a different unit of
measure.

the wrong fill level error was 100% human. Though based on unit
issues, the error was 100% human. No documents or otherwise were wrong.

[Janis Papanagnou]

I see. So professional publishing would have some "style control"
in practise, IIUC.

Would those quasi standards/guides also be sort of authoritative in
the decision what is to be taught to children at school? Or is that
part of the education (i.e. WRT language) arbitrary?

If I extrapolate from those style guides, over the schoolbooks (that
would probably be published by companies considering those guides),
to the schools and pupils, I suppose the situation is not as bad as
the other poster's comment made me suspect.

Janis, still curious about that "wondrous land, in a world the lord
himself designed" :-)

PS & BTW:
Is this signature depicted in that image a sign of illiteracy...
http://cdn4.spiegel.de/images/image-445893-panoV9free-epdo.jpg
(I thought that would generally be written as 'X', at least in
Nethack - it's time to come back to some on-topic track.)

[Janis Papanagnou]

Am 10.01.2013 14:05, schrieb MrTallyman:
> On Thu, 10 Jan 2013 08:40:28 +0100, Janis Papanagnou
> <janis_pa...@hotmail.com> wrote:
>
>>> The US incident WRT that Mars space probe clearly was a problem
>>> of using and mixing non-standard units.
>

> It was absolutely operator error. He assumed a different unit of
> measure.
>
> the wrong fill level error was 100% human. Though based on unit
> issues, the error was 100% human. No documents or otherwise were wrong.

Umm, yes. Wasn't that the issue that mixing units is bad for human use?
And striving to use common standards would have helped to avoid that?
(I mean, at least in some future, when even the last industrial country
will have changed.)

Janis

[jim in austin]

The Elements of Style, also known as The Little Book, is one you are likely to encounter in high school or university English but it is not without its critics:
http://en.wikipedia.org/wiki/The_Elements_of_Style

[Doug Freyburger]

Janis Papanagnou wrote:

> rpresser wrote:
>> Janis wrote:
>>> [*] Remember that US space probe that missed a planet!?
>
>> You mean just like the Japanese space probe missed Venus in 2010?
>
> They consistently used SI and missed, or what? Please elaborate.
>
> The US incident WRT that Mars space probe clearly was a problem
> of using and mixing non-standard units.

They are parallel at lesson level one, not parallel at lesson level two.

Level one - Going to other planets is very difficult to get right.
Beyond just rocket science it's the hard part of rocket science.

Level two - Any type of mixing units makes everything harder.