# It's A Date!

As you might imagine, someone who writes robots designed to automatically mange opt-in content or daemons - designed to run unattended for decades - might have some relatively interesting time and date calculation requirements. Indeed, when tracking appropriately-recurring day-content containing holidays, events, and other falderal is more important than hours, many folks like to use

**Julian Days.**

# Day Julian?

The problem is, whenever we try to universally define exactly *what* any computationally useful encoding might look like, opinions can differ wildly. While some insist that 'day zero' is important, others disagree. -Speculation also rages over just how far back, and forward, an official year and / or day-count might reach. Rather than haggling over the exact time of a technically unmeasurable origin, how about coining a more

*event-relative*time-reckoning?

# Count-Downs

Living close to NASA, like others we have always been inspired by the mathematical possibilities of the "T - 1" form of event-counting. -Being computer geeks, we also recognize that using negative numbers can also have some decidedly plotable graphical & computational advantages.

# Concepts Encoded

For the above (and other) reasons therefore, we decided to come up with

*our own*definition of what a better

*Julian Date*should look like.

### -Negative Years

Honoring the mathematicians of The Roman Empire, only "Day 1, Year 1" will be encoded in event origination; Honoring the needs to align both computational & graphical symmetry, years

*before*"Day 1", are negative. (We feel that using negative and positive numbers might be a better way to mathematically express concepts such as "BC" or "AD"?)

### -Counting Days

Next, while incrementing / decrementing days AFTER an event are logical, things like decrementing the time BEFORE an event must be logically identical, yet mathematically inverted. (Time, after all, indeed has a somewhat forward bias?) Hence increasing or decreasing a pre-event calculation should ever maintain the same linear motion as do those same operations in the event's positive complement.

Consequently our new Julian

**series before & after any event is:**

*year # day*... -1#3 ... -1#2 ... -1#1 ...

**[event]**... 1#1 ... 1#2 ... 1#3 ...

### -Leap Years

For 'galactic reasons' (not all planets share the same number of days in their year after all!) note that the number of days & years around any event are completely customizable. -For the sake of conveyance to us 'Terrans however, by default the number of days in a leap-year remain as presently calculated.

### -The Potentia

Finally, across all celestial bodies, adjusting for leap-years remains a somewhat arbitrary process. Because some years are allowed to have more days in them than others, we refer to the

*potential maximum number of days*across all years as being the

**. By way of example, while the usual number of days for our orb is 365, the potentia for Mother Earth is**

*potentia***366**.

(While one might be tempted to apply Earth's

**n+1**formula to calculate the potentia everywhere, some conditions may require the scheduling of an event every

**n**''years'' yet - just as predictably - routinely lasting much longer than

*+1*days. Because the length of any schedulable, mathematical-rounding additive can obviously vary, the potential must be customizable.)

# Try It

Therefore, submitted for your consideration please find our

**DateJulian**class. -The guiding basis for all that our robotic endeavors deliver to-you on the Internet, I hope that you might find our "Julian Day with +/- Year" event-management concepts as invaluable, as we do.

Here is where you can download our JavaDoc, Test Case, & Source Code.

Enjoy!

-R.A. Nagy

[ view entry ] ( 2975 views ) | permalink | related link

Just a quick note to let everyone know that we just released another version of [ClassIO]. Still a Java tool, but we plan to create one for C# as time permits.

Enjoy,

-Rn

[ view entry ] ( 1620 views ) | permalink | related link

I am reminded that it is good to remember that we can use templates to take advantage of "isa:" In C# and Java specifically, since all classes are reference types (object pointers), the universal object-placeholder is

**Object**. From a template's point of view, Everything '

**isa**n' Object.

What does having a universal Object for

*absolutely all*classes, mean? -Well, much like using "void *" in C/C++, Java and C#'s

**Object**offers us all of that polymorphic goodness, as well as some sophisticated base operations.

To demonstrate the former, given the following template + interface combination:

public interface OmniAdapter<T> {

// Adapter: Convert one object, to another

Object xForm(T ref);

}

-We can support a simple child 'Object'-conversion:

public class Event3 extends Day2

implements OmniAdapter<Day2> {

public MyNewClass xForm(Day2 ref)

{

return new MyNewClass(ref);

}

}

What is interesting to keep in-mind here is that, because

*MyNewClass*is-an

**Object**, that we can

*xForm*one type, to another. -Even if

*MyNewClass*is only used by a single, solitary function - as long as the compiler can find it - then we can return it.

Enjoy,

-Rn

[ view entry ] ( 2160 views ) | permalink

<<First <Back | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | Next> Last>>