Re: Comparison of Invalid Dates FW: Best Before 29 Feb 2006 RE: Y 2K++

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Comparison of Invalid Dates FW: Best Before 29 Feb 2006 RE: Y 2K++

VictorEngel
Dear Karl,

> KARL SAYS: Actually one could make a valid comparison with 12
> NEVER 2004, provided the date you compare is of a different year. E.g.
>
> 1 January 2003 BEFORE 12 Never 2004 is TRUE
> 12 December 2005 BEFORE 12 Never 2004 is FALSE
> 12 Never 2004 BEFORE 16 Octember 2005 is TRUE
> 12 Never 2004 BEFORE 12 December 2004 is INVALID
> 12 Never 2004 BEFORE 12 December Wah! is INVALID

Are you sure? The reason I question this is something I overheard on the
radio the last time I rode the bus. The dispatcher was looking for a driver
who could pick up a partial shift from 2400 to 2700 hours. For shift work
there are more than 24 hours in a day even though there are only 24 hours in
a day. For example, 0000 to 0300 is the same time as 2400 to 2700, but
Charles is still working Monday from 2400 to 2700 whereas Peter is working
Tuesday from 0000 to 0300.

I imagine the same sort of thing could be done with calendars. Today, for
example, is the first day of the first four week month of 2006 (assuming
weeks beginning Monday).

From a computer sciences perspective, though, I think the distinction Karl
is making separates the date into three fields. If the date were
stored/conceptualized as a single field, such a comparison is not possible.

Victor
Reply | Threaded
Open this post in threaded view
|

Re: Comparison of Invalid Dates FW: Best Before 29 Feb 2006 RE: Y 2K++

Palmen, KEV (Karl)
Dear Victor and Calendar People

-----Original Message-----
From: East Carolina University Calendar discussion List
[mailto:[hidden email]]On Behalf Of Engel,Victor
Sent: 12 December 2005 15:42
To: [hidden email]
Subject: Re: Comparison of Invalid Dates FW: Best Before 29 Feb 2006 RE:
Y 2K++


Dear Karl,

> KARL SAYS: Actually one could make a valid comparison with 12
> NEVER 2004, provided the date you compare is of a different year. E.g.
>
> 1 January 2003 BEFORE 12 Never 2004 is TRUE
> 12 December 2005 BEFORE 12 Never 2004 is FALSE
> 12 Never 2004 BEFORE 16 Octember 2005 is TRUE
> 12 Never 2004 BEFORE 12 December 2004 is INVALID
> 12 Never 2004 BEFORE 12 December Wah! is INVALID

Are you sure? The reason I question this is something I overheard on the
radio the last time I rode the bus. The dispatcher was looking for a driver
who could pick up a partial shift from 2400 to 2700 hours. For shift work
there are more than 24 hours in a day even though there are only 24 hours in
a day. For example, 0000 to 0300 is the same time as 2400 to 2700, but
Charles is still working Monday from 2400 to 2700 whereas Peter is working
Tuesday from 0000 to 0300.

KARL SAYS:
I thought of that idea a few years ago and let CALNDR-L know about it. The idea being that one can than chose when the date begins, but always counts the hours after the last midnight on or before the date start.

If this idea were applied to years. Then all the 12 Never comparisons would be invalid.

For example, one could call JANUARY and FEBRUARY, UNDECIMBER and DODECIMBER respectively in a year that begins on 1 March, two months late.

VICTOR CONTINUED:
I imagine the same sort of thing could be done with calendars. Today, for
example, is the first day of the first four week month of 2006 (assuming
weeks beginning Monday).

From a computer sciences perspective, though, I think the distinction Karl
is making separates the date into three fields. If the date were
stored/conceptualized as a single field, such a comparison is not possible.

KARL SAYS: Yes if the year could not be parsed from the date.

Karl

07(15(12
Reply | Threaded
Open this post in threaded view
|

Re: Comparison of Invalid Dates FW: Best Before 29 Feb 2006 RE: Y 2K++

Lance Latham
In reply to this post by VictorEngel
RE:

> Are you sure? The reason I question this is
> something I overheard on the
> radio the last time I rode the bus. The dispatcher
> was looking for a driver
> who could pick up a partial shift from 2400 to 2700
> hours. For shift work
> there are more than 24 hours in a day...

Lance replies:
One may likewise refer to, say, the 37th day of
November, which is a date in December, and so on,
provided that the convention is clear. This is simply
a convenience for the purpose of using a base 'epoch'
for certain purposes, such a shift work. Calendric
computation often identifies a 'January 0' or 'March
0', for example.

If that convention is not being explicitly followed,
then an expression involving the hour unit with a
value of '27' is simply invalid.

If the bus in question was in Austin, of course, then
the explanation is simple error. I narrowly missed
ridng the 'Manchaca' Austin city bus to the city of
Manchaca one evening, for example. Referring to the
drivers as 'idiots' would be an insult to idiots
everywhere.


> From a computer sciences perspective, though, I
> think the distinction Karl
> is making separates the date into three fields. If
> the date were
> stored/conceptualized as a single field, such a
> comparison is not possible.

Lance replies:
(a) There is no necessary restriction concerning the
number of fields. The basic concepts still apply to a
date written with, say, 6 time units.

(b) If the date is reduced to a single field, than
something quite different has occurred, viz., that an
interval is being reduced to an instant, or that a
particular convention is being applied. An interval
has duration, an instant does not. For convenience of
calculation, we often reduce a date to a corresponding
Julian Day number. The JD# convention, however,
implicitly states an interval in that convention.

A date reduced to, e.g., the JD# 2400000 represents,
in this convention, an interval which is typically
2399999.5 to 2400000.5 (Gregorian).

Note that this convention is very different from
taking 2400000, an integer, to be 2400000.0, a real
number, which represents an instant (noon). For this
reason, I distinguish a 'JD0' (integer) from a 'JD'
(real) when programming.

One may also consider the case that a 'single field'
can also have its own conventions for representing
intervals. Taking the common case of the JD# as an
example, suppose one adopts the convention that a zero
to the left of the decimal point always represents
uncertainty in an interval, provided that all
positions to its right are also zero. Then using that
convention, a value such as 2456700 would represent an
uncertainty on the order of 100 days, that is, an
interval of 100 days duration.

If one thinks about this situation at all, I believe
that it is possible to come to the conclusion that all
of technical chronology, including calendric
computation, is actually a special case of interval
temporal logic, and all the rules and results of ITL
apply.

If one considers that all time units, whether
centuries or nanoseconds, are actually intervals, that
relation becomes very clear.

-Lance


Lance Latham
[hidden email]
Phone:    (518) 274-0570
Address: 78 Hudson Avenue/1st Floor, Green Island, NY 12183
 




__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 
Reply | Threaded
Open this post in threaded view
|

Re: Comparison of Invalid Dates FW: Best Before 29 Feb 2006 RE: Y 2K++

VictorEngel
In reply to this post by VictorEngel
Dear Irv and Calendar People,

>
> The Reingold & Dershowitz generic procedure for determining if a date
> is valid, which can be used with any calendar at all and any date
> regardless of the leap rule or anything about the calendar structure,
> is to use an appropriate function (such as theirs) to convert the
> separated date to a rata die, and then the inverse function
> to convert
> the rata die back to the separated calendar date.  For example, using
> their CCME function definitions:  fixed-from-gregorian, followed by
> gregorian-from-fixed.  If the separated date that comes back is the
> same as the original date, then the date is valid, otherwise it is
> invalid.

It seems to me that this doesn't say anything about the dates but about the
function and inverse function.

Victor
Reply | Threaded
Open this post in threaded view
|

Re: Comparison of Invalid Dates FW: Best Before 29 Feb 2006 RE: Y 2K++

Irv Bromberg
On Dec 12, 2005, at 17:01, Engel,Victor wrote:

> Dear Irv and Calendar People,
>> The Reingold & Dershowitz generic procedure for determining if a date
>> is valid, which can be used with any calendar at all and any date
>> regardless of the leap rule or anything about the calendar structure,
>> is to use an appropriate function (such as theirs) to convert the
>> separated date to a rata die, and then the inverse function to convert
>> the rata die back to the separated calendar date.  For example, using
>> their CCME function definitions:  fixed-from-gregorian, followed by
>> gregorian-from-fixed.  If the separated date that comes back is the
>> same as the original date, then the date is valid, otherwise it is
>> invalid.
>
> It seems to me that this doesn't say anything about the dates but
> about the
> function and inverse function.
>
> Victor

BROMBERG replies:

Victor, "it seems to me" that you didn't give the matter much thought
before writing your comment quoted above!

It might help to illustrate using the Rectified Hebrew Calendar (RHC)
as an example, because compared to the Gregorian Calendar the RHC has a
greater need to check if a date is valid, since ANY month can have 29
or 30 days (varying from year-to-year), plus there is an entire leap
month that is only present every 2 or 3 years.  Please see:

<http://individual.utoronto.ca/kalendis/hebrew/rect.htm#valid>

If one prefers to work with Julian Days, just use an appropriate
function that converts the given calendar date to a Julian Day number,
followed by a function that converts the Julian Day number back to a
calendar date.  If the returned calendar date is the same as the given
calendar date then the given calendar date is a valid date on that
calendar.  Alternatively one could employ the Modified Julian Day
number, or the Windows date serial number (if no dates prior to 1900
are required), etc.

This method does not indicate what PART of the given date was wrong,
however, just that the date is invalid.  Further discussion in this
regard, mostly of generic applicability, is under the heading "Computer
Algorithms for Checking if a Symmetry454 date is Valid" on page 18 of
the Symmetry454 arithmetic PDF which can be downloaded from:

<http://www.sym454.org/symmetry/>


-- Irv Bromberg, Toronto, Canada

<http://www.sym454.org/>
Reply | Threaded
Open this post in threaded view
|

Re: Comparison of Invalid Dates FW: Best Before 29 Feb 2006 RE: Y 2K++

Palmen, KEV (Karl)
In reply to this post by VictorEngel
Dear Victor and Calendar People

-----Original Message-----
From: East Carolina University Calendar discussion List
[mailto:[hidden email]]On Behalf Of Engel,Victor
Sent: 12 December 2005 22:01
To: [hidden email]
Subject: Re: Comparison of Invalid Dates FW: Best Before 29 Feb 2006 RE:
Y 2K++


Dear Irv and Calendar People,

>
> The Reingold & Dershowitz generic procedure for determining if a date
> is valid, which can be used with any calendar at all and any date
> regardless of the leap rule or anything about the calendar structure,
> is to use an appropriate function (such as theirs) to convert the
> separated date to a rata die, and then the inverse function
> to convert
> the rata die back to the separated calendar date.  For example, using
> their CCME function definitions:  fixed-from-gregorian, followed by
> gregorian-from-fixed.  If the separated date that comes back is the
> same as the original date, then the date is valid, otherwise it is
> invalid.

It seems to me that this doesn't say anything about the dates but about the
function and inverse function.

KARL SAYS: What is said about the functions implies something about the dates. The fact that 300 March 2005 is converted to the same rate die as 25 December 2005 implies that the two dates are equivalent, while the conversion of that rata die back to 25 December 2005 implies that 25 December 2005 is valid and 300 March 2005 is not valid.

Karl

07(15(13

Victor