[TYPO3-dev] ADOdb extended dates prototype

[Christoph Koehler]

On Mon, 21 May 2007 09:34:58 -0500, Ernesto Baschny [cron IT]  
<ernst at cron-it.de> wrote:

> Christoph Koehler wrote: on 21.05.2007 15:52:

> I thought your extension added some user setting where he can choose
> which TZ he is in. I didn't test it, that what I though when reading
> your code.

Yes it does, but as you mentioned, that's kind of obsolete.

> The "us-mode" setting is really a bit ugly, but this doesn't affect TZ
> calculations at all. It just switches days with months (mm.dd.yyyy
> instead of dd.mm.yyyy) in the "human readable" output that the client
> displays in date/datetime fields. Having different preferred date format
> in input-fields might get some ugly results, so I prefer to keep that
> setting "global". E.g. I must enter "dd.mm.yyy" when I am logged in as
> user "eu-user" and "mm.dd.yyy" when logging in as "us-user".

Tell that the content editor that is used to doing it her way. There are  
no ugly results because you set your preference, and whatever you type in  
is evaluated based on your preference. Pretty simple, and everyone can use  
their favorite date format!

> I thought the main benefit of using adodb was to use negative timestamps
> to be able to represent dates before 1970. Dates after 2038 are also
> nice, but I think not so important right now than being able to
> represent the birthday of people that are over 37 years old in a regular
> "date" field.

PHP on unix support negative timestamps as well, going down to like 1902  
or so. The advantage of ADOdb is that instead of 32-bits, the timestamps  
can now be 64 bits, signed.

> So for doing negative dates, we need a SIGNED INT field, where we
> currently have a UNSIGNED INT.

Right, in Unix. Windows PHP doesn't support negative timestamps. I am  
actually not sure how ADOdb handles that on Windows, but I am sure it  
works :)

> Having a nice date-manipulation API might come very handy, but I think
> for frontend stuff this might be a candidate for inclusion in the "cal"
> extension. "cal" already has to perform several date manipulations.

That's fine with me.

> But my idea would be not to "misuse" the current "date" and "datetime"
> eval fields, because that would mean rewriting every extension that
> expects that fields to hold UNSIGNED INTs. I would rather add a new
> "adodate" or "bigdate" and "bigdatetime" eval fields that handle that
> new situation. This way we guarantee backwards compatibility, we have
> two new eval field types which internally use adodb and maybe some fancy
> JS for client-side calculation (maybe regular new Date() from JavaScript
> already handle signed bigint's???). New extensions can make use of those
> fields, old extensions still work, but upgrades might change to the new
> fields. Old eval types are marked as "deprecated" now and nobody is
> encouraged to use them.

That'll work for me.

>> 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.
>
> Are there other "date formats" than dd.mm.yyyy and mm.dd.yyyy? Keep in
> mind that the separator character is currently "flexible", you could
> even enter "ddXmmXyyyy" in that field. We could have a configurable
> separator for dates, so that instead of "-" it could be "." or "/". But
> that would only change the human readable output, because the parsing
> and stuff would work the same way as today.

yyyy/mm/dd. Don't know anyone using it, but with my solution you can use  
dd/yyyy/mm if you want. I never saw the separator being configurable. But  
as far as I know you can enter dates in any format, but it won't stay that  
way in the input fileld.

> And if JS already handles signed bigints in Date() object, that is
> pretty much all we need to support adodb-dates.

I guess except for changing the db fields to bigints, TYPO3 might already  
handle those dates very well. That's interesting.
Someone mentioned pear::date, as well. Haven't looked at it, but will do  
that to see if it might be better than ADOdb.

> Cheers,
> Ernesto