In beta 6:

 if (preg_match("/^(\d{4})-(\d{2})-(\d{2}) ([01][0-9]|2[0-3]):([0-5][0-9]):([0-5][0-9])$/", $yvalue))
            $yvaluedate = strtotime($yvalue);
          else
            $yvaluedate = $yvalue;

The check with preg_match is gone in beta 7, breaking the rendering with GVS of my data from a custom table which uses integer timestamps as dates. In the generated JavaScript code, there is instead of 'new Date(...)' always 'undefined' as the strtotime() call on a timestamp results in a null value.

Comments

btomic’s picture

btomic commented

Do you use integer database filed or timestamps field?
Timestamps database field views knows how to handle and, I think, it will not make problems. I think, the problem is if field is integer and views treats it as number and not converts it in appropriate form. So, I will make some addition in code to convert numbers to dates in that cases.

cyberwolf’s picture

cyberwolf commented

It concerns UNIX timestamps, so integers, coming from the database, indeed. Not fields of type datetime (like CCK Date uses I guess).

I am wondering why you would want to convert numbers to dates first if what you need is actually the number? See the code above that was in Beta 6. The strtotime() call is still there in beta 7 but is executed unconditionally, to convert a datetime to a UNIX timestamp (integer).

btomic’s picture

btomic commented

Main idea was to use datetime and timestamp database fields for dates and use views handlers (but there is views problem datetime fields). Integer fields can treat as timestamp or as year. So it can cause problem in interpreting and I have removed possibility of using anything except valid date in beta7 (but, if you have some suggestion how to handling integers...). In meantime I will return possibility to use integers as timestamps.

btomic’s picture

btomic commented
Status: Active » Closed (fixed)