reply the answer

[Richard Tobin]

Leap year computations are not at all difficult; tweaking the epoch to
make them easier would not be worthwhile.

A reasonably complete date library would have an is_leap_year()
function. No doubt it would depend on the locale (e.g. for Russian
locales 1900 would be a leap year).

-- Richard

 

[Walter Roberson]

A reasonably complete date library would have an is_leap_year()
function. No doubt it would depend on the locale (e.g. for Russian
locales 1900 would be a leap year).

Indeed, if I understand correctly, the Muslim calendar has non-trivial
disagreements over intercalculary days, and even the formalized
"what could have been observed if it had been clear enough" versions
depend upon longitude and lunar timings (but lunar cycle times are
not completely regular, being affected by tides, wobble, ice coverage,
gravitational density of the part of the Earth being passed over...)

 

[Spiros Bousbouras]

Keith Thompson said:

Right. <tgmath.h> has "special-interest group with lobbying expertise"
written all over it.

For my general education what's wrong with tgmath.h ?

 

[Richard Heathfield]

Spiros Bousbouras said:

For my general education what's wrong with tgmath.h ?

It's unnecessary, except to a very few people who already use Fortran
anyway.

 

[Old Wolf]

"AD 1" is the traditional usage.

The year didn't start in January back then. September was
the 7th month,

According to Wikipedia, the year has started on
1 Jan since 153 BC. (Look up Roman_calendar). They
named their years after the current Roman consuls,
who took office on 1 January.

 

[Old Wolf]

A reasonably complete date library would have an is_leap_year()
function. No doubt it would depend on the locale (e.g. for Russian
locales 1900 would be a leap year).

A complicated issue. In the Gregorian calendar, 1900 was
a leap year regardless of where you are. No doubt you're
referring to the fact that they were still using the
Julian calendar in Russia at that time.

I think it is more sensible for each locale to use
the calendar that is currently in use for that locale
today, and display past dates proleptically. For
example, most of us talk about "AD 332", or "45 BC"
despite the fact that the AD epoch was not introduced
until AD 525. You wouldn't call for the en-US locale
to display pre-Columbus dates in Native American format,
would you?

 

[Old Wolf]

A complicated issue. In the Gregorian calendar, 1900 was
a leap year regardless of where you are.

Should say, was NOT a leap year.

 

[Spiros Bousbouras]

Spiros Bousbouras said:



It's unnecessary, except to a very few people who already use Fortran
anyway.

Are you saying that something as basic as sin() is
unnecessary ?

 

[Keith Thompson]

"AD 1" is the traditional usage.


According to Wikipedia, the year has started on
1 Jan since 153 BC. (Look up Roman_calendar). They
named their years after the current Roman consuls,
who took office on 1 January.

Yes, but read on. Until a few centuries ago, many European countries
started the new year on March 25, December 25, or even Easter, though
calendars still displayed the months from January to December.
England, for example, didn't change its New Year's Day from March 25
to January 1 until 1752, the same year it adopted the Gregorian
Calendar.

I suppose that means that the day after March 24, 1750 was
March 25, 1751. Must have been fun.

To steer back to topicality, I wouldn't want C's time and date
functions to reflect this chaos (unless, in a hypothetical new time
and date library, you specifically ask for it).

 

[Keith Thompson]

Are you saying that something as basic as sin() is
unnecessary ?

sin() is declared in <math.h>, and has been for many years.

<tgmath.h> merely adds type-generic macros (which are useful, I
suppose, if you can't be bothered to remember which type you're
operating on.)

Incidentally, in C90's <math.h>, the only sine function is
double sin(double x);
C99's <math.h> adds:
float sinf(float x);
long double sinl(long double x);
That's another C99 feature that I wouldn't want to throw away.

 

[Old Wolf]

Yes, but read on. Until a few centuries ago, many European
countries started the new year on March 25, December 25, or
even Easter, though calendars still displayed the months
from January to December.

We were talking about what happened in AD 1.
Wikipedia doesn't explicitly say, but it seems
reasonable that the Romans would have called
it "1 Jan, Year of Foo and Bar", where Foo and
Bar were the newly-elected consuls -- rather
than continuing to use the names of the deposed
consuls for a couple of months.

Anyway, this is moot, as RH was talking about
Gregorian 1 Jan, AD 1 -- which is not even the
same as Julian 1 Jan and is not affected by
whatever the locals called that day!

 

[CBFalconer]

Keith Thompson wrote: [...]

I've very tempted to advocate requiring the epoch to be
1970-01-01 00:00:00, just for the sake of compatibility with the
most common practice.

Any such case should be based on 1968, 1972, 1900, or even the
mythical year 0, to ease computation of leap years.

Leap year computations are not at all difficult; tweaking the epoch
to make them easier would not be worthwhile. And setting the epoch
to 1968 or 1972 wouldn't make the century-based rule any easier.

Now try converting between day of year and month/day, etc. A pain.

 

[Keith Thompson]

Keith Thompson wrote: [...]
I've very tempted to advocate requiring the epoch to be
1970-01-01 00:00:00, just for the sake of compatibility with the
most common practice.

Any such case should be based on 1968, 1972, 1900, or even the
mythical year 0, to ease computation of leap years.

Leap year computations are not at all difficult; tweaking the epoch
to make them easier would not be worthwhile. And setting the epoch
to 1968 or 1972 wouldn't make the century-based rule any easier.

Now try converting between day of year and month/day, etc. A pain.

Sure. Is the pain significantly lessened by setting the epoch to 1968
rather than 1970? I think not. Adding or subtracting 1968 is no
easier or harder than adding or subtracting 1970.

 

[Richard Heathfield]

Old Wolf said:

"AD 1" is the traditional usage.

In your tradition, maybe. Not in mine. During my schooling (and as far
as I can recall, even since then), every reference book I saw that had
cause to mention AD put it *after* the year number. Whenever my
teachers (history, RE) needed to use "AD", they used it as a suffix to
the year number, not a prefix. 1 AD is, as far as I am concerned, the
traditional usage. (Cf "2000 AD", the Judge Dredd comic - so obviously
some Usanians agree with me.)

 

[Richard Bos]

Not quite. If it's a fixed-point type with a minimum resolution and a
minimum range, it becomes trivial to extend either the resolution or the
range by adding more bits at one end or the other; for a fixed-resolution
tick counter, adding more range is easy (just use a wider type), but
adding more resolution would require going from an integer type to
a floating-(or fixed-)point type, which Would Be Problematic if the
counter were required (by standardization or by custom) to be an integer.

Nah. All you need to do is up the resolution from milli- to
micro-seconds. Or float the fixed-point fixed point three digits to the
left. Except in terminology, it's exactly the same thing; the effects
are identical, it's only the names that differ.

Richard

 

[Richard Bos]

We were talking about what happened in AD 1. Wikipedia doesn't
explicitly say, but it seems reasonable that the Romans would
have called it "1 Jan, Year of Foo and Bar",

So much - again - for the reliability of Pikiwedia. The Romans didn't
number their days as we do. The first day of Januari would have been
Calendae (or Kalendae) Januarii.

Richard

 

[Richard Bos]

I think it is more sensible for each locale to use
the calendar that is currently in use for that locale
today, and display past dates proleptically.

Up to a point, because...

For example, most of us talk about "AD 332", or "45 BC"
despite the fact that the AD epoch was not introduced
until AD 525. You wouldn't call for the en-US locale
to display pre-Columbus dates in Native American format,
would you?

....no, but I would display pre-Gregorian dates in the Julian calendar.
Charlemagne died on the 28th of January 814, not somewhere in February.
(And here the fun starts already: what do you do when you talk about a
date in the Julian calendar, when you're talking _in_ a country that had
already accepted the Gregorian calendar by that time? For example, on
what day, according to a program running in Roma, did Elizabeth I die?
And that's just the beginning. Hence my prediction: we won't have a
_properly_ thorough time handling system for another decade yet.)

Richard

 

[Richard Tobin]

...no, but I would display pre-Gregorian dates in the Julian calendar.
Charlemagne died on the 28th of January 814, not somewhere in February.
(And here the fun starts already: what do you do when you talk about a
date in the Julian calendar, when you're talking _in_ a country that had
already accepted the Gregorian calendar by that time? For example, on
what day, according to a program running in Roma, did Elizabeth I die?
And that's just the beginning. Hence my prediction: we won't have a
_properly_ thorough time handling system for another decade yet.)

And such a system should be a separate standard, not part of the C
standard itself.

-- Richard

 

[Chris Dollin]

1 AD is, as far as I am concerned, the
traditional usage. (Cf "2000 AD", the Judge Dredd comic - so obviously
some Usanians agree with me.)

Why "obviously"? 2000 AD is /British/.

 

[Richard Bos]

Why "obviously"? 2000 AD is /British/.

_Very_ British.

As for 1 AD or AD 1, it's Anno Domini uno, not unum Anno Domini - in the
Year of our Lord nr. 1, not in one year of our Lord.

Richard