This bug came up in node/1017866 and was fixed for Date/ISO field types, but not Unix timestamps.

Steps to reproduce:

* Install latest dev version of Date module on vanilla D7 install
* At admin/config/regional/settings, select "America/New York -0500" as site default TZ, and allow users to set their own TZ.
* In admin user's profile, unset TZ or select "America/New York"
* Edit the out-of-the-box Article content type at admin/structure/types/manage/article/fields. Add a new "Date (Unix timestamp)" field with the Select List widget.
* On the Field Settings for the new Date field, unselect the Hour and Minute attributes. Also unselect Day and Month if you wish. Note that the "Time zone handling" select box disappears when you unselect the Hour attribute. (there is form validation in the Date module that specifically checks that tz_handling is empty if you deselect the Hour attribute)
* Create a new Article. In your Date field, input 1 Jan 2016 (or Jan 2016, or 2016, depending on your granularity). Save the Article.
* Create a new test user. Set this user's timezone to "Pacific/Gambier -0900".
* View the article as both the admin account (or anonymous user) and as the test account.

Here's what the admin and anonymous users see:
http://i.imgur.com/uA6F2Sp.png

Here's what the test account sees:
http://i.imgur.com/Vkxow2A.png

Comments

caesius created an issue. See original summary.

caesius’s picture

caesius’s picture

Title: Unix timestamp date types do not handle timezones with large granularity » Date (Unix timestamp) fields do not perform proper timezone conversion with large granularities