[TYPO3-dev] ADOdb extended dates prototype

[Ernesto Baschny [cron IT]]

Christoph Koehler wrote: on 22.05.2007 19:12:

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

Agreed.

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

Why do you need the clients timezone information on the server? Isn't it
enough to just pass the UTC time from client to server?

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

You mean that filling the "_hr" (human readable) field should also be
done in that ajax call? I would agree that this would make more sense
for the consistency.

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

I thought the "custom date format" are a matter of input in the backend.
Why should an extension bother what the date format was? The extensions
should work with the unixtime that is stored in the database. Or am I
getting something wrong here?

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

Input fields with custom date formats should be consistent on all date
fields. With "custom date formats" you mean that the user can choose
whether he likes "dd.mm.yyyy" or "mm-dd-yyyy" or even "yyyy-mm-dd" for
his date fields, right? This should be then used consistently on all
functions that output dates in backend (in labels, list view, etc).
Shouldn't be that hard to make that change.


Cheers,
Ernesto