[TYPO3-dev] ADOdb extended dates prototype

[Ries van Twisk]

Excuse me for not reading the whole tread,
I read about bigints and such... But why not use the native
timestamp support by all database typo3 'supports'.

Get rid of the integers and use a timestamp where you can store every  
time
in there including timezone information and all problems are solved.

I believe adodb's library was just created for situations where a  
timestamp
could not be used because of limitations of Mysql (if I remember  
correctly that is)

in this case we have modern databases and timestamps will work much  
better
then bigints.

just MHO.

Ries



On May 21, 2007, at 8:52 AM, Christoph Koehler wrote:

> 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
> _______________________________________________
> TYPO3-dev mailing list
> TYPO3-dev at lists.netfielders.de
> http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-dev

-- 
Ries van Twisk
Freelance Typo3 Developer
email: ries at vantwisk.nl
web:   http://www.rvantwisk.nl/
skype: callto://r.vantwisk