Re: [Mvpmc-devel] timestamps

[Simon H. <si...@ic...>]

On Mon, 23 Jun 2008, Tom Metro wrote:

> Roger Heflin wrote:
>> It is ascii and it is being encoded with one int per part (ie 6/27/2008
>> is 3 bytes) and (10:23:15) is 3 more ints...
>
> I assume you mean 3 ints rather than 3 bytes in the first example.
>
>
>> ...and then 1 more int for something else...
>
> Did you figure out what for?
>
>
>> I was thinking of avoiding the time_t so that we don't have to worry
>> about things not matching what is actually in the mythtv database...
>
> True. You've got leap seconds and other complications that could make
> the conversion not precisely reversible.

Meh, I'm not convinced we'd ever actually hit any of these problems.

>> ...since each number above is under 256...we could use unsigned chars...
>
> OK, so 6 bytes instead of the 28 bytes you previously mentioned. 2 more
> bytes than a 32-bit time_t, but 2 bytes less than a 64-bit time_t, which
> is really what we should be using these days. So that sounds like a good
> approach.

I already moved a whole bunch of code elsewhere in the SQL bits of 
libcmyth over to using time_t (32-bit). I don't see 64-bit time_t's as a 
particularly sensible thing to work with on the MediaMVP at the moment.
I'm not even sure if uclibc has support for them. If we stick to using 
time_t and the standard functions for dealing with it for now then it 
shouldn't be difficult to convert to 64-bit when it's feaable and the nead 
arises.

>> ...though we may have to manually do packing/unpacking...
>
> I see you've updated your dongle with a patch for this, so I take it you
> were able to inject this change in storage format with minimal code impact.

I think I'd prefer that we went for time_t...It is one heck of a lot 
easier to deal with programmatically than a bunch of seperate quantities 
for each of the units. Since most of the mythtv timestamp code is in its 
own library, it shouldn't be difficult moving this over to using a time_t 
internally.

Cheers,

Simon