Date to 4 byte string

  • Thread starter Thread starter Steve
  • Start date Start date
S

Steve

Hi All,

I have a registration code that currently has 4 bytes that are unused.
I'd like to store a future date in those 4 bytes. Is there a way to
convert a date to a 4 byte string?

When I do something like this,

string stringDate =
DateTime.Parse("1/15/2210").ToBinary().ToString("X");

I get a hex # 15 characters long.

Any suggestions? I only have 4 bytes to work with to stay backward
compatible.

Thanks,
Steve
 
Steve said:
Hi All,

I have a registration code that currently has 4 bytes that are unused.
I'd like to store a future date in those 4 bytes. Is there a way to
convert a date to a 4 byte string?
Click to expand...

Let's see. 4 bytes will hold an unsigned 32-bit integer. Convert the date
into number of days past some specific date, and store it as that.
 
Hi,

I think you could do it, you could use one byte for the day, one for the
month and you have two for the year.
 
Hi All,

I have a registration code that currently has 4 bytes that are unused.
I'd like to store a future date in those 4 bytes. Is there a way to
convert a date to a 4 byte string?
Click to expand...

Not in a general purpose way. However, you could easily pick a
specific reference date, and then store the total number of days from
that date as the future date. 4 bytes gives you a 32-bit counter, and
you can represent a date VERY far in the future with that as your
number of days. :)

Actually 32-bits is (as you can see from the above) a pretty large
amount of data for the kind of information you're trying to store. So
depending on your desires and needs, you could waste some space making
the 4 bytes a little more readable and likely still come up with
something usable. For example, one byte each for day of month and
month of year, and then two bytes for the year. That would still allow
you to represent absolute dates (rather than the relative suggested
above) through the year 65535. 65536 if you're willing to take
advantage of the fact that there's no 0 AD.

This all assumes the usual Western Gregorian calendar. Your mileage
may vary depending on other calendars you might use, if any.

Pete
 
Michael A. Covington said:
Let's see. 4 bytes will hold an unsigned 32-bit integer. Convert the
date into number of days past some specific date, and store it as that.
Click to expand...

Another possibility: Consider the date as a yyyymmdd string, for
instance, 20071231 (you can chhose a different format, of course, but this
one will be advantageous if you need to sort by date). Then store those 8
digits in your 4 bytes, 2 digits per byte. This will be easier to read than
"number of days from a specified date" if you ever have to look at a hex
dump of your data.
 
Steve said:
I have a registration code that currently has 4 bytes that are unused.
I'd like to store a future date in those 4 bytes. Is there a way to
convert a date to a 4 byte string?
Click to expand...

One thing no-one else has mentioned: strings aren't comprised of bytes.
They're comprised of *characters*. Now, do you need a 4-byte data
structure of any description, or an actual 4 character string?

If you can use 4 bytes in an arbitrary fashion, using an int is likely
to be the best solution. 4 characters would be a different matter.
 
One thing no-one else has mentioned: strings aren't comprised of bytes.
Click to expand...

That's true.
They're comprised of *characters*.
Click to expand...

That's not. :) A string may _comprise_ characters. It's not
_comprised of_ characters, it's _composed of_ characters.

Sorry, pet peeve. But if people keep misusing "comprise" like that,
we're left with a word that used to be a perfectly useful word but
which is now just a useless synonym for "compose".

I hope your editor doesn't let you get away with stuff like that in
your book. :)
Now, do you need a 4-byte data
structure of any description, or an actual 4 character string?
Click to expand...

Now that is a very good point. As is sometimes the case, I and others
have fallen into the trap of assuming the OP has asked a question that
correctly reflects what he really wants to do. But you're right, his
question is ambigious and he should clarify whether he has 4 bytes or 4
characters to use.

Interestingly, if the latter then my personal opinion is that his
options are possibly actually more restricted than if he had 4 bytes.
Though the native .NET String format is 2 bytes per character,
typically one would not want to store invalid characters or characters
that wouldn't be correctly represented in some external storage.

So unless he could guarantee the string (assuming it is really a
string) is stored as some Unicode format, he'd want to limit himself to
at least regular, printable 8-bit characters (e.g. the Windows "ANSI"
or similar), if not to the printable subset of 7-bit ASCII. That
significantly would reduce the possible number of combinations
available below what a regular 32-bit binary data value would allow.

Ah...nothing is ever as simple as it first looks. :)

Pete
 
Jon, if this (below) converts back - and - forth:

int myDate = 20071105;
byte[] b = BitConverter.GetBytes(myDate);
Console.WriteLine(b.Length.ToString() + " bytes.");
// reads "4 bytes"
// And -back again:
Console.WriteLine("Orignal: " +BitConverter.ToInt32(b,
0).ToString());

-- then converting a dateTime object eg '11/05/2007' (US)
to the corresponding integer above is simple. Yes?
Peter
--
http://www.eggheadcafe.com
unBlog: http://petesbloggerama.blogspot.com
BlogMetaFinder: http://www.blogmetafinder.com
 
Jon, if this (below) converts back - and - forth:

int myDate = 20071105;
byte[] b = BitConverter.GetBytes(myDate);
Console.WriteLine(b.Length.ToString() + " bytes.");
// reads "4 bytes"
// And -back again:
Console.WriteLine("Orignal: " +BitConverter.ToInt32(b,
0).ToString());

-- then converting a dateTime object eg '11/05/2007' (US)
to the corresponding integer above is simple. Yes?
Click to expand...

Storing a date in a 32-bit value is simple regardless, whether you use
the encoding you've demonstrated or some other. That's not the point
of Jon's post. The question Jon raises is that it's possible that the
OP has 4 characters, not 4 bytes, in which to store the data.
Depending on how those characters are stored, the OP could have more
flexibility or less as compared to a 32-bit data field.

Of course, if it really is a 32-bit data field in which the OP can
store the data, then the character question is moot. But we don't know
whether that's the case or not, until the OP clarifies his scenario.

Pete
 
Peter Duniho said:
That's not. :) A string may _comprise_ characters. It's not
_comprised of_ characters, it's _composed of_ characters.

Sorry, pet peeve. But if people keep misusing "comprise" like that,
we're left with a word that used to be a perfectly useful word but
which is now just a useless synonym for "compose".

I hope your editor doesn't let you get away with stuff like that in
your book. :)
Click to expand...

That's what I get for posting with my son anxious to play a Lego City
game :)
Now that is a very good point. As is sometimes the case, I and others
have fallen into the trap of assuming the OP has asked a question that
correctly reflects what he really wants to do. But you're right, his
question is ambigious and he should clarify whether he has 4 bytes or 4
characters to use.

Interestingly, if the latter then my personal opinion is that his
options are possibly actually more restricted than if he had 4 bytes.
Though the native .NET String format is 2 bytes per character,
typically one would not want to store invalid characters or characters
that wouldn't be correctly represented in some external storage.
Click to expand...

Exactly. It's interesting that a larger storage option is more
restrictive. It really depends on what's going to happen to it.
 
Yes, understood. When we look at the OP's code sample:

string stringDate =
DateTime.Parse("1/15/2210").ToBinary().ToString("X");

-- he is looking for a way to get a string (even if a HEX string).

I believe it is reasonably clear that because he is using an overload of
"ToString" that means (to him) somehow a character in a string is equivalent
to a byte.
 
One thing no-one else has mentioned: strings aren't comprised of bytes.
They're comprised of *characters*. Now, do you need a 4-byte data
structure of any description, or an actual 4 character string?

If you can use 4 bytes in an arbitrary fashion, using an int is likely
to be the best solution. 4 characters would be a different matter.
Click to expand...

Sorry I wasn't more clear. In my original post, I did mean bytes, not
characters. However, I later found that I had made a mistake and I
was looking at 4 bits; not 4 bytes. I doubt very seriously if anyone
can think of a way to store a date in 4 bits. Still, thanks to
everyone for their suggestions.

The only option I can now see is to modify the structure of our
original registration code. So much for backward compatibility. :-(

Steve
 
Yes, understood. When we look at the OP's code sample:

string stringDate =
DateTime.Parse("1/15/2210").ToBinary().ToString("X");

-- he is looking for a way to get a string (even if a HEX string).

I believe it is reasonably clear that because he is using an overload of
"ToString" that means (to him) somehow a character in a string is equivalent
to a byte.
Click to expand...

"Reasonably clear" is in the eye of the beholder. Suffice to say, I
disagree that anything about the original question is actually
"reasonably clear", in the sense that it's unambiguous. If anything,
the things you point to as making the question "reasonably clear" are,
in combination with the rest of what he wrote, the things that to me
prevent the question from being "reasonably clear".

Taken by themselves, you could make the assumptions you've made. But
taking the post as a whole, there are too many inconsistencies for the
question to be "reasonably clear".

Pete
 
Back
Top