Encoding Date/Time

[PNP]

I need to fine the current date/time add x hours & y minutes to
it. I then need to send it through IPC to a different process which
can read this & find the sent time.

What is smallest number of bytes I need for sending this data?
i.e. How many bytes is that data guaranteed to fit in?

 

[Andrew Poelstra]

I need to fine the current date/time add x hours & y minutes to
it. I then need to send it through IPC to a different process which
can read this & find the sent time.

What is smallest number of bytes I need for sending this data?
i.e. How many bytes is that data guaranteed to fit in?

1. Try comp.programming, because this isn't really a C question.
2. You need to provide more information about how much data actually
needs to be exchanged.

Having said that, you can encode a date as a 4-byte UNIX timestamp,
which will work until sometime in 2038. An eight-byte value would
be better.

But those assume you need second precision. For networking you may
need more or less. Again, you should post more information.

 

[Thad Smith]

I need to fine the current date/time add x hours & y minutes to
it. I then need to send it through IPC to a different process which
can read this & find the sent time.

What is smallest number of bytes I need for sending this data?
i.e. How many bytes is that data guaranteed to fit in?

That depends on the desired range. A single octet works for a four hour range.
Two octets gives a range of 45 days. Etc.

 

[Nick Keighley]

I need to fine the current date/time add x hours & y minutes to
it. I then need to send it through IPC to a different process which
can read this & find the sent time.

What is smallest number of bytes I need for sending this data?
i.e. How many bytes is that data guaranteed to fit in?

this is unanswerable without more information. Before I read other
people's posts I assumed you only wanted the time to the minute. Since
there are 1440 minutes in a day you can get the time into 10.5 bits.
If you program sends regular updates you might get away with a delta
(add x minutes to the last value)

 

[jacob navia]

Richard Heathfield a écrit :

Let's assume that our calendar will survive indefinitely in its present
form, and that you are happy with a granularity no finer than seconds.

An instant in time, then, can be described by these components: seconds
(0-59 - we'll ignore leap-seconds); minutes (0-59); hours (0-23); days
(0-30); months (0-11); and years.

Leaving years aside for the time being: if we wish to store mdhms as
separate data elements, we need a minimum of 26 bits. If we are prepared
to combine them, maybe we can save some bits. We could simply store the
number of seconds in a year, which, in a leap year, could be
approximately 31557600. This value can be stored in 25 bits. Okay, so we
saved one single bit. (Is that a worthwhile saving? Probably not. But
you asked for the smallest number of bytes, and that suggests that we
should try to economise on every possible bit.)

Now let's think about years. If we try to fit a year value into 7 bits
(which is tempting, since it gives us 32 bits altogether), the biggest
number we can have is 127 (in which case the smallest would be 0). We
could say "okay, let's use that to describe the year range 2010 to
2137", in which case the answer to your question is 32 bits. But if we
want something more durable than that, or if we need to extend into the
past, then we will need more bits.

If you're happy with a 128-year range, then, you will need 32 bits,
which is guaranteed to fit into 4 bytes, because a byte is guaranteed to
be at least 8 bits wide. Bytes can be wider than that, though, so you
might be able to squeeze 32 bits into fewer bytes on some systems.

If we just store the date as the number of seconds since a given instant
(say January First 2000 0:00) we can store 136 years in an unsigned 32
bits, 9 years more than using Mr Heathfield's schema



Storing all the bits as a SINGLE number avoids bit waste.

If you store for instance the hours as 6 bit number you waste
some bit space since 6 bits goes up to 0-63 but you use up to
59 only. Worst is month that can be stored in 4 bits but uses only up to
12 positions from the available 16. All this waste accumulates. We gain
9 years.

 

[Nick]

this is unanswerable without more information. Before I read other
people's posts I assumed you only wanted the time to the minute. Since
there are 1440 minutes in a day you can get the time into 10.5 bits.
If you program sends regular updates you might get away with a delta
(add x minutes to the last value)

If the IPC protocol has a time in the header, you could send a delta
from transmission time and then the number of bytes you need depends
solely how far x and y can be from the time of transmission.

 

[BGB / cr88192]

And starting at 1/1/2000 knocks 10 years off, which means that your schema
expires before mine.

But yes, you're right in general.

Having said that, if we bite the bullet, forget the minbits requirement,
and settle for 64 bits, we can not only make decoding a little bit easier
but also massively extend the range:

bits 0-5: second
bits 6-11: minute
bits 12-16: hour
bits 17-21: day
bits 22-25: month
bits 26-63: year

38 bits for the year gives us a range of 0 to 274877906943, which "ought
to be enough for anybody".

<snip>

we can also just use the unix timestamp format, but put the unix timestamp
in the middle:
16 bits for a fractional second, making it accurate to around 15us;
+16 bits to the year, giving a signed range of +-2228224 years (from 1970)
or so...

this also makes it trivial to convert to/from unix timestamps within the
"valid" range.

also possible is to add ~20 bits to the second (and thus only ~12 to the
year), which is similarly, not particularly difficult to convert...