[FLOW3-general] DateTime limited to Unix timestamp?

[Michael Sauter]

On 01.07.10 21:12, Jigal van Hemert wrote:
> Michael Sauter wrote:
>> On 01.07.10 14:00, Jigal van Hemert wrote:
>>> If I read it correctly, FLOW3 still uses the Unix timestamp to store
>>> dates. Wouldn't this be a good opportunity to move to a 64-bit format?
>> I had a look at date & time in PHP recently and think the best way of
>> doing it is the way FLOW3 handles it.
>
> You mean handling it as a (internally 64-bit) DateTime object in PHP and
> storing it in the database as a 32-bit number? Hmm...
>
>> If I'm not mistaken, the unix timestamp is only limited to 2038 on
>> 32-bit systems, not on 64-bit. And here's hope there won't be any
>> 32-bit systems around in 28 years ;)
>
> Storing a timestamp in an INTEGER field in the database will limit it to
> 4 bytes (if I understood the ANSI specs correctly the range defined for
> a normal INTEGER is the same as that of a 32-bit signed integer).
> Database systems have invented 8 byte numbers for some time, so these
> could be used for bigger timestamps.
>
> Thinking that a system will be replaced in x years is something that was
> proven wrong a little over a decade ago.

True :) But the case is a bit different here I think. The problem with 
Y2K was that the stored values were not sufficient. Here, not the value 
is the problem, but the possible range ...

> The most important issue is that it's not about 32-bit versus 64-bit
> *systems*. A Unix timestamp will suffice for some time to store creation
> dates of files (for which it was meant), but what about birthdays of
> historical figures? Events in the past and future like solar eclipses [1]?
>> There's still the problem with dates before 1970 (not 1901) though ...
>
> Well, I'm not the only person in the world who's been born before that
> year.
>
> It would be rather strange for a brand new system from the 21th century
> which uses cutting edge technology to support only dates between 1970
> and 2038, wouldn't it?

Yep. Definitely weird ;) But are there better solutions worth the 
trade-off? Sometimes you don't need DateTime handling anyway. Let's take 
your example of birthdates of historical figures. Probably you won't 
need timezone handling there, so it might be enough to store the date as 
a simple string (and also use it as a string, a DateTime object seems 
like overkill to me there). I do understand there might be situations 
where you actually want to have more control/options, but I'd say these 
(rare?) cases might justify building a custom way to store the 
information (e.g. splitting up information into different DB fields and 
combining them upon reconstitution)  ...

~michael