[TYPO3-dev] ADOdb extended dates prototype

[Christoph Koehler]

On Tue, 22 May 2007 10:49:52 -0500, Ernesto Baschny [cron IT]  
<ernst at cron-it.de> wrote:

> Christoph Koehler wrote: on 21.05.2007 23:26:
>
> I think we always will have some problems in that area, as the gregorian
> date switch depends also on local adoption (1582 in christian countries,
> but for example 1927 in turkey). So you would need to know in which
> country the date refers to if you want to be precise.

Yeah agreed. I don't think that can be handled client side either, so it's  
bad either way.

> Ok with me, I just think that this overhead is not needed as JavaScript
> already has a pretty robust Date() object to make client side  
> calculations.

Yeah it does and I thought the server call wouldn't be necessary, but if  
we make ext devs compute timestamps using ADOdb and not use that when  
users enter dates, we might get different results, so this decision is  
more one of consistency.


> If you convert them to UTC anyway, why do you need to contact the server
> for getting a timestamp? Just to be sure you handle the gregorian switch
> correctly?

See above. The timezone would just be passed along to the server.

>> That would mean your patch will not be needed. I heard you guys thought
>> it through very thoroughly, so I want to be sure I get everything right.
>> By the time you read this I probably have a new version of extdates
>> already released for you guys to consider, I just wanted to post this
>> anyway.
>
> Sounds cool, lets keep it rolling. I think this is a matter that we
> always have in debate but nothing really ever changed since. So having
> some test code and experience with that might enlighten us a bit more
> and point towards the correct direction.

Sounds good. Sorry for not having anything ready yet, something came up so  
I didn't have the time.
One thing we kept thinking about was consistency, so we did decide to use  
new eval fields for the new dates, as  David wanted to see in his other  
post.
We also decided to change the current eval slightly to implement the  
custom date format for users. Whether that will be just client side or  
server side as well I don't know yet. It would certainly be easier to do  
it server side because all the code is already there and speed shouldn't  
be an issue.
Just enabling custom date formats for extended dates would result in  
inconsistencies between extensions that already have switched to the  
extended ones and those who haven't.
So it's either enabling it on all date and time fields or not doing it at  
all. I will give that one up for discussion some more while I code the  
other features around it :)

Thanks for the feedback guys!

Christoph