# Represent Date in 4 digits?

I dates lke 04/01/2013. I have 4 digits [0-9] to represent that date. Is is possible to do this, ie to mux/demux it somehow?
If not, I may be able to have 4 chars [0-9][a-z]. It is possible with that?
ThomasMcA2

Are you asking if you can represent a date, including the year, with only 4 characters? No, not that I've ever seen.
mds-cos

membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
What range of dates do you need to represent?
The rest of the year?  The rest of century?  Back to 600 BC?

IC devices use a four digit date code -- Week 01 to 52  and the last two digits of the year.

You could do hundredths of a year (00 to 99) and last two digits of the year (assuming the century).  That is as efficient as you can get with 4 digits.
We don't want to forget the lessens we learned about Y2K for a while yet.
Oh - sorry...wrong math!  If you use characters you will have a range of days that equals (however many unique characters you use) ^ 4.

Of course your math becomes more complex since you will have to convert from characters to numbers to perform the mathmatical offset.
Lessons learned from Y2K -- if you program your code to become obsolete, you will assure jobs for future programmers ;-)

Sorry, I just couldn't resist!  Been there, done that, kept the world running, laughed at the non-technical people who were in fear and panic mode.

But in all seriousness, if you do start date offset the point I made about giving your code a life-span is very specific to Y2K type issues.  Depending on what your program does, limiting it to a 27 year date range might be perfectly acceptable.

If the language you are programming in supports HEX math functions, you can easily get 179 year range (16^4) without worrying about any additional conversions.  Just use 0 - F as your character set and do HEX math to add the offset.

Year range is like 1900 - 2100

Maybe I could use [0-9][a-f] for a hex number.
Your earlier remark (last in original question) makes it easily possible: using characters [0-9][a-z] you can use 1 position for day, 1 for month and 2 for year (since 1900). Search online for "base 36 conversion".
4 chars [0-9][a-z] is enough to represent over 4000 years of unique dates.
4 hex digits can cover a little less than 180 years.
Just beat me to it ozo ;-) I was about to post: A quick test reveals that storing days since 1900 in 4 hex numbers should work until may 27, 2079...
SOLUTION

membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Robert,

I like your year offset with day specifies idea.  The only thing to consider when choosing to offset just the year or offset the entire date by days is programming language.

Some languages have built-in date addition support, allowing final date to be a simple matter of (year to show) = (base start date) + (day offset).  If this is supported, it makes for simpler program code than breaking the date elements apart to calculate individually.
Ok, I'll ask.  What reason do you have for using a totally non-standard date format?  All the programming languages and databases I know of have well developed routines for handling dates.  I guess if you want to make something incompatible with all other date functions, this will do it.
4 chars [0-9][a-z]

that gives you a range of 4,600 years as opposed to 27 years with 0-9

now all you need is an algorithm!

convert to days since 1900, then change to number base 36

_______________________________________________________________

what language do you want?  VB, c#, javascript, c/c++?

Well, since you asked ... C#

I'm much better at Java, though for this I really do need C#. Wrote this real quick. Not a finished product. Despite my earlier comment, 2000 is the start year.

``````import java.util.Calendar;
import java.util.GregorianCalendar;

public class DateMux {

private final int START_YEAR = 2000;
private final int MONTHS_IN_YEAR = 12;

private String monthString;
private String dayString;
private String yearString;

private int dayNumber;

public DateMux(String dateString) {

String delimiter = "/";
String[] tokenArray = dateString.split(delimiter);

monthString = tokenArray[0];
dayString = tokenArray[1];
yearString = tokenArray[2];

System.out.println ("DateMux: " + monthString + "/" + dayString + "/" + yearString );

}

public void mux() {

final int month = Integer.parseInt(monthString);
final int day = Integer.parseInt(dayString);
final int year = Integer.parseInt(yearString);

int cumulativeDays = 0;

//System.out.println ("DateMux: " + month + "/" + day + "/" + year );

for (int y = START_YEAR; y <= year; y++) {

int lastMonth = MONTHS_IN_YEAR;

if (y == year) {
lastMonth = month;
}

for (int m = 1; m <= lastMonth; m++) {

Calendar calendar = new GregorianCalendar(y, m-1, day); // month appears to be 0-based
final int daysInMonth = calendar.getActualMaximum(Calendar.DAY_OF_MONTH);
//System.out.println ("DateMux: month: " + m + "\tdaysInMonth: " + daysInMonth);
int lastDay = daysInMonth;

// if last year and last month
if ((y == year) && (m == lastMonth)) {
lastDay = day;
}

for (int d = 1; d <= lastDay; d++) {
cumulativeDays++;
}
}

}

//System.out.println ("DateMux: cumulativeDays: " + cumulativeDays );
String cumulativeDaysHexString = Integer.toHexString(cumulativeDays);
System.out.println ("DateMux: " + dateString + "\tcumulativeDays:  " + cumulativeDays  + "\t" + cumulativeDaysHexString + "h");

}

public void demux() {

}

/**
* @param args
*/
public static void main(String[] args) {

String dateString = "03/01/2013";

DateMux dateMux = new DateMux(dateString);

dateMux.mux();

}

}``````
The clarifying question about "Why do you want to do this?" can be important. Date values are commonly kept in 4-byte values, i.e., 32-bit integers; but that's not quite the same as "4 characters".

Is it certain that the requirement is "4 characters" and not "4 bytes"? A character representation would usually only be useful for human-readable values. But only a very few possibly gifted individuals could ever actually interpret the values.

Tom
And come to think of it, is there a definition of "character" that should be used? The Unicode character sets can be large enough to hold 100 years of dates in single "characters".

Tom