[TYPO3-dev] ADOdb extended dates prototype

[Christoph Koehler]

On Tue, 22 May 2007 13:08:54 -0500, Ernesto Baschny [cron IT]  
<ernst at cron-it.de> wrote:

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

All we get from the client is the date string. It's passed to the server  
and there transformed into a timestamp which is then put into the hidden  
input field.
There are actually two calls to the server. One to get the date string to  
the server, and one to get a date string back from the server given a  
timestamp. That is necessary because the date string entered might be  
"t+3" which is sent to the server, transformed into a timestamp and put  
into the hidden field. That timestamp is then sent to the server in the  
output js function to get a real date string back that is then put into  
the _hr field.
Maybe there is a better way?


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

Yeah, I explained some of that above. Maybe there is a better way of  
reducing redundancy here.

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

Yes you are :) The custom date format is a matter if input and output for  
input fields as well. The output in the _hr field right now is always  
mm-dd-yyyy or the US equivalent, but always with "-". The custom date  
format changes that.
This is built into the evaluation, and since we decided to use separate  
eval categories for the extended dates, they would be available only where  
those extended fields are used. So if an extension uses the normal eval  
categories, it would still output dates with "-"; those who use the  
extended fields would output whatever format the user specified. That's  
inconsistent. So I said we either also add the custom date format stuff to  
the existing date eval categories that won't be using extended dates, or  
we don't do it at all.
Hope that made sense.

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

Yeah that's what I am hoping. See above for some more on that. We either  
do it on all fields, or none, to be consistent.
A note on precedence: The install tool has a setting called mmddyy or  
similar that defines a date format. That one is used by default. There is  
also an option via userTS that I added, setup.default.dateFormat I think,  
that will take precedence over the install tool setting if it's available.  
Finally there is the field in the User->Setup module, which is the final  
authority on date format. So the admin can set it in the install tool and  
probably userTS for different users or groups, and the user can pick one  
himself, too.
So we get: user setting > userTS > install tool setting.

Christoph