Jay Pipes wrote:
> Michael Widenius wrote:
>> Hi!
>>
>>>>>>> "Oystein" == Oystein Grovlen <ystein> writes:
>>
>> Oystein> Konstantin Osipov wrote:
>>>> * Øystein Grøvlen <Oystein.Grovlen@stripped> [09/05/22
> 21:05]:
>>>>> So far my Value object knows nothing about arithmetics, all they
>>>>> know about is how to convert between types. However, it needs to
>>>>> distinguish between more than just four types. For example,
>>>>> conversion between integer and string will be different for a
>>>>> Field_timestamp than for a Field_long.
>>>> This just doesn't make sense to me. It's like saying that
>>>> conversion between an integer and a string will be different
>>>> depending whether this integer represents a datetime or, well, an
>>>> integer.
>>>> Isn't it easier to say (and code) that a conversion from an
>>>> integer to a string is not the same as conversion from a datetime to
>>>> a string? What am I missing?
>>
>> Oystein> That's really what I tried to say. Both integer and datetime
>> will Oystein> internally be represented by a longlong, but the
>> conversion from Oystein> longlong to string will be different.
>>
>> Plese don't do that!
>>
>> We want to add microsecond support to datetime and having datetime as
>> longlong would make this quite hard to do!
>
> Not really. Lay the bits out like so:
>
> | 63 | 62 | 61 | 60 | 59 | 58 | 57 | 56 |
> | JD | JD | JD | JD | JD | JD | JD | JD |
> | 55 | 54 | 53 | 52 | 51 | 50 | 49 | 48 |
> | JD | JD | JD | JD | JD | JD | JD | JD |
> | 47 | 46 | 45 | 44 | 43 | 42 | 41 | 40 |
> | JD | JD | JD | JD | JD | JD | JD | JD |
> | 39 | 38 | 37 | 36 | 35 | 34 | 33 | 32 |
> | JD | JD | JD | uS | uS | uS | uS | uS |
>
> | 31 | 30 | 29 | 28 | 27 | 26 | 25 | 24 |
> | uS | uS | uS | uS | uS | uS | uS | uS |
> | 23 | 22 | 21 | 20 | 19 | 18 | 17 | 16 |
> | uS | uS | uS | uS | uS | uS | uS | SS |
> | 15 | 14 | 13 | 12 | 11 | 10 | 09 | 08 |
> | SS | SS | SS | SS | SS | SS | SS | SS |
> | 07 | 06 | 05 | 04 | 03 | 02 | 01 | 00 |
> | SS | SS | SS | SS | SS | SS | SS | SS |
Actually, come to think of it, storing microseconds in the lowest bits
would be even better, since temporal values could be compared directly
as uint64_t's ...
> Where:
>
> JD = Julian Day Number
> uS = microseconds up to 1,000,000
> SS = seconds in day up to 86400
>
> Julian Day Number stored in 27 bits will limit the capacity of the field
> to -4713 B.C to July 23rd, 362763 A.D. but I think that's sufficient :)
>
> Cheers,
>
> Jay
>
