Working with dates and views we observe that there was a problem when filtering dates using date API, searching I found that by default, from date_views_argument_handler_simple class, it set the date_sql_handler without an offset and no timezone. If date_sql_handler, is using the local_timezone site default, wouldn't be logical to use the default time zone offset?

<?php
/**
   * The object constuctor.
   */
 
function __construct($date_type = DATE_DATETIME, $local_timezone = NULL, $offset = '+00:00') {
   
$this->db_type = db_driver();
   
$this->date_type = $date_type;
   
$this->db_timezone = 'UTC';
   
$this->local_timezone = isset($local_timezone) ? $local_timezone : date_default_timezone();
   
$this->set_db_timezone($offset);
  }
?>
Files: 
CommentFileSizeAuthor
#3 date-handling-default-timezone-date-handler-1714762-0.patch946 bytesalmul0
PASSED: [[SimpleTest]]: [MySQL] 5,238 pass(es).
[ View ]
#1 date-handling-default-timezone-date-handler-1714762-0.patch945 bytesalmul0
FAILED: [[SimpleTest]]: [MySQL] Invalid PHP syntax in sites/default/modules/date/date_api/date_api_sql.inc.
[ View ]

Comments

almul0’s picture

Version:7.x-2.5» 7.x-2.x-dev
Status:Active» Needs review
StatusFileSize
new945 bytes
FAILED: [[SimpleTest]]: [MySQL] Invalid PHP syntax in sites/default/modules/date/date_api/date_api_sql.inc.
[ View ]

I made a patch for my project.

I think it would be great to merge it with the principal development branch to avoid that issues in the future.

Regards

Status:Needs review» Needs work

The last submitted patch, date-handling-default-timezone-date-handler-1714762-0.patch, failed testing.

almul0’s picture

Status:Needs work» Needs review
StatusFileSize
new946 bytes
PASSED: [[SimpleTest]]: [MySQL] 5,238 pass(es).
[ View ]

I forgot semicolon...

KarenS’s picture

Status:Needs review» Closed (works as designed)

No, the lack of an offset in that function does not mean it's local, it means we don't know anything about the offset and that we're not going to try to force one in. You patch would change the way that lots of other parts of the code work, so I can't make this change.

almul0’s picture

Ok.

Maybe, I patched the wrong file/submodule, cause I had the problem described above using views.

Perhaps the problem is in date_views when we create an instance of the class date_sql_handler. If I alter those calls in date_views, maybe the changes won't affect the rest of the code or the api. Isn't it?

Thanks anyway,

grisendo’s picture

Assigned:almul0» Unassigned
Status:Closed (works as designed)» Needs review

How does this affect to other parts exactly? Do you have any tests for the module?

In fact, you are assuming timezone is always +00:00.

When saving date fields without time granularity (and no timezone conversion selected) in database gets stored correct value, but filtering breaks it.

i.e:
In a Unix timestamp date field with "year" granularity (and no timezone conversion), it gets stored 1356994800 (which is "2013-01-01 00:00:00").
But filtering by year 2013, there are no results.
Filtering by 2012, I can get the result of the node with year 2013, just like if time was converted to "2012-12-31 23:00:00" in the query (my timezone is Europe/Madrid).

This patch solves my problem, for fields with granularity "year", "month", and "day"... and also with "hour", "minute" and "seconds" with time before is 00:00 for example.