[TYPO3-dev] ADOdb extended dates prototype

[Ernesto Baschny [cron IT]]

Christoph Koehler wrote: on 21.05.2007 15:52:

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

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.

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

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

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.

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

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.

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.

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

It can be, check out the mentioned patch which is in the previously
mentioned bug report. That was the solution Mario Matzulla and I found
during the TYPO3 Developer Days. The patch already entered the core
list, but currently we've got very little feedback from users, which is
why core members are probably holding back with reviewing. The more
feedback we get from users that NEED those bugs fixed, the better
changes we have to integrate that in 4.2.

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

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

Cheers,
Ernesto