[FLOW3-general] DateTime limited to Unix timestamp?

[Michael Sauter]

On 07.10.10 20:41, Jigal van Hemert wrote:
> Hi,
>
> On 7-10-2010 21:12, Michael Sauter wrote:
>> just remembered this thread and thought I could do something about it.
>
> This discussion was briefly quoted in a thread in the typo3.english
> newsgroup [1] and Xavier "DBAL" Perseguers noted that any decent DBMS
> supports a DATE/DATETIME datatype.
>
> Advantage is also that it can be used directly in queries to compare
> other dates, convert it to certain formats, etc.
>
> I think Xavier's knowledge can be very useful when it comes to making
> decisions about how to store data in a cross DBMS supported way.
>
> [1] http://typo3.toaster-schwerin.de/typo3_english/2010_09/msg00162.html

Hi,

thanks for pointing out that thread (it's kinda crazy how distributed 
information is sometimes :))

While I agree that it would be very useful to use some sort of 
DATE/DATETIME datatype, I don't think it is a good idea to rely on them. 
FLOW3 abstracts the complete storage away. Because of this, potentially 
any database could be used. For example, CouchDB [1] can "only" store 
String, Number, Boolean, Array and Object. Now I don't know if CouchDB 
would be a good fit for FLOW3, but I would consider it a "decent" DBMS. 
It's just not relational (and doesn't use SQL). And there are many more 
systems like CouchDB that do not support specific date/time datatypes.

I also think that it would be great to have a non-relational database 
backend for FLOW3 at some point, because it could fit much better with 
DDD approach taken (also for scaling/performance reasons).

So, in order to be able to switch the underlying database without 
changing client code, FLOW3 would need to use only datatypes that are 
available everywhere. And as stated above, I think switching the 
database to some "NoSQL" database is IMHO thinkable and probably even 
desirable ... and this, in turn would cancel out the use of 
DATE/DATETIME (which is a concept widespread only in the SQL world).

Again, happy to discuss or being corrected, but I think replacing the 
current integer storage with a string based version might be the most 
flexible solution and should be worth the effort (it doesn't seem to be 
to complicated).

~michael


[1] http://couchdb.apache.org/