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 |
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
