[TYPO3-dev] ADOdb extended dates prototype

[Christoph Koehler]

On Mon, 21 May 2007 07:52:44 -0500, Ernesto Baschny [cron IT]  
<ernst at cron-it.de> wrote:

> That looks cool. But have you seen my proposed change in
> http://bugs.typo3.org/view.php?id=1697? This fixes the problem with
> client-side calculation. Only "features" missing would be:

Briefly looked over it, will take another look and maybe apply the patch  
locally to keep your changes when I make mine.

> - Having a client with a TZ setting on his machine and a different TZ
> setting in TYPO3. Is this required? common? neeeded? What sense does
> that make?

Didn't know that was there :) That would make things easier of course, at  
least for timezone. One goal was to allow the user to choose any date  
format he wants and deprecate the US mode install tool setting. So we  
still need some kind of setting in TYPO3 for that.

> - Using adodb for storage: This is a nice addition in your extension!
> And this is the one I would find most interesting to get into the Core.
> But I would like to know a bit more about it: How does the DB has to be
> changed to be able to store those values? What about extensions that
> make use of this date fields directly?

The db fields need to be changed to bigint because normal int fields are  
only 32-bit. The maximum digits for a 64-bit date is 19 I think, so that  
needs to be changed from 11 digits as well, even though 19 digits  
timestamps will very likely never happen. Nor will 18 digit ones. Or 17.  
You get the point.
I was thinking about adding some methods to the API that deal with  
retrieving dates from the db while at the same time taking care of all the  
timezone etc issues. Until then I am afraid a manually retrieved date will  
make no sense to the extension if it's beyond the 32bit limit, i.e. 2038,  
and if the normal PHP date functions are used.

> To me it looks that calling the server to get timestamps for all dates
> is a bit of an overkill, while we could just make all calculations on
> client side. Despite having duplicate "checking" code (server + client
> side), are the other reasons for doing so?

Yeah I need to look into that some more. ADOdb timestamps are still just  
seconds since 1970, and all that TYPO3 does is compute the seconds  
difference. It all relies on the JS Date() object, which seems to support  
dates past the 32-bit limit, so TYPO3 does indeed support extended dates,  
it just can't save it in the db.
The reason I used AJAX was that I assumed that it couldn't be handled  
otherwise.

I think we can get rid of the server call. We just add the date format  
option like Kasper added the US mode and use it to evaluate the input  
string client side. So we only need adodb server side, either directly or  
via some API wrapper.

What do you think?

Christoph