I had a project where on a node type I wanted a date field that would save only the year.
So I created a new date field on the node type and selected the field type to be Date (Unix timestamp).
Next on the Field settings page I started to uncheck the Date attributes to collect, leaving only the year.
And here is were the problem occurs.
Once I removed the Hour component, the Time zone handling select-list disappears, with a default value of "Site's time zone".
This later lend to problems with the date values that were being saved in the Database since my website's timezone is GMT +2, so actually by selecting 2015 it would result in 2014 December 30 22:00 being saved in the Database.
I believe that the default value of the Time zone handling for the field type: Date (Unix timestamp), should be UTC, since it only really makes sense to have a timestamp based on UTC.

CommentFileSizeAuthor
#9 date-timestamp_timezone-2460143-9.patch1.28 KBLiam Morland
#6 date-timestamp_timezone-2460143-6.patch1.22 KBLiam Morland
#2 date-timestamp_timezone-2460143-2.patch1.22 KBmaximpodorov
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

martichka5’s picture

martichka5 CreditAttribution: martichka5 commented

Hello,

I think I have a similar problem. When we collect only year, month and day without hour, the displayed date (in format "time ago") is not shown properly. The date is calculated with the previous date. The same happens when we use strtotime function for example.
entered date = 2015-03-26 after strtotime = Wed, 25 Mar 2015 23:00:00 GMT

Any help would be appreciated.
Thank you in advance!

maximpodorov’s picture

maximpodorov CreditAttribution: maximpodorov commented
Version: 7.x-2.8 » 7.x-2.x-dev
Component: User interface » Code
Category: Feature request » Bug report
Status: Active » Needs review
FileSize
date-timestamp_timezone-2460143-2.patch1.22 KB

I suggest to change 'tz_handling' setting for timestamp fields. Timestamps are always in UTC, so 'site' value seems appropriate one for all timestamps.
The patch forces this setting change upon field settings editing (no hook_update yet).

Status: Needs review » Needs work

The last submitted patch, 2: date-timestamp_timezone-2460143-2.patch, failed testing.

jonloh’s picture

jonloh CreditAttribution: jonloh as a volunteer commented
Status: Needs work » Needs review

I've tested it and it seems to be filtering accurately now.

Here's an additional step which I did in order to get it to work - Once you patch the file, re-save your nodes which have the date field that needs to be filtered in Views.

I would suggest for others to test the patch to ensure it work fine in different scenarios.

rooby’s picture

rooby CreditAttribution: rooby commented
Priority: Minor » Normal

This also fixes my problem of trying to compare a year/month/day unix timestamp with 'today' in a view.

Liam Morland’s picture

Liam Morland
Primary language English
Location Ontario, CA 🇨🇦
CreditAttribution: Liam Morland at University of Waterloo commented
FileSize
date-timestamp_timezone-2460143-6.patch1.22 KB

Untested re-roll of #2.

Status: Needs review » Needs work

The last submitted patch, 6: date-timestamp_timezone-2460143-6.patch, failed testing.

rooby’s picture

rooby CreditAttribution: rooby commented
Status: Needs work » Needs review

[EDIT] Whoops, I didn't see the testbot

Liam Morland’s picture

Liam Morland
Primary language English
Location Ontario, CA 🇨🇦
CreditAttribution: Liam Morland at University of Waterloo commented
FileSize
date-timestamp_timezone-2460143-9.patch1.28 KB

Patch #6 with test error fixed.

Chris Matthews’s picture

Chris Matthews CreditAttribution: Chris Matthews as a volunteer commented

The 2 year old patch in #9 to date_admin.inc still applied cleanly to 7.x-2.x-dev. Is anyone able to confirm this issue is ready for RTBC?

Checking patch date_admin.inc...
Hunk #1 succeeded at 617 (offset 2 lines).
Hunk #2 succeeded at 629 (offset 2 lines).
Applied patch date_admin.inc cleanly.