The profile module uses format_date() to display birthdays of users. Since format_date() tries to add zone information to the dates, the actual displayed dates differ from the actual birthday depending on the user zone.

Probably, function _profile_user_view() in profile.module should either use date() directly or format_date() should have an additional flag to specify that the date should NOT be adjusted for timezone differences.

- Sandip

Comments

moshe weitzman’s picture

moshe weitzman commented

From your description, it sounds like everything is working correctly now. User enters birthday *in his own time zone*. We adjust and then store UTC in the database. On display, we adjust again depending on the viewer's time zone ... Maybe you have legacy data which needs updating now that dates work correctly.

Also, be sure you are using latest sources. Date handling has been worked on recently.

sandip-1’s picture

sandip-1 commented

The date is not stored in UTC in the database. In the "data" column of the relevant record in the user table, the following value is stored which corresponds to my birthday of 16 December 1974:

  s:16:"profile_birthday";s:2:"16";s:18:"profile_birthmonth";s:2:"12";s:17:"profile_birthyear";s:4:"1974";

Maybe I am wrong here, but when I tell someone that my birthday is 16/12/1974, that _is_ always my birthday regardless of which timezone my audience is from. I dont care if the date where the person stays was 15/12/1974 or not. My birthday always remains the same. I think my assumption is correct, because otherwise birthday columns filled in different parts of the world for the same person will differ.

There doesnt seem to me any reason to adjust timezone for a birthday. This date is immutable regardless of the audience.

- Sandip

moshe weitzman’s picture

moshe weitzman commented

Oh. Whomever implemented this was way ahead of me. You are right that birthdate is considered immutable ... either of your proposed solutions would work. please submit a patch.

sandip-1’s picture

sandip-1 commented

The following patch works for now:

--- profile.module.orig Fri Oct 31 00:10:37 2003
+++ profile.module      Fri Oct 31 00:11:49 2003
@@ -209,7 +209,7 @@
             if (isset($user->profile_birthday) && isset($user->profile_birthmonth) && isset($user->profile_birthyear)) {
               // this is very european-centric, can we use format_date?
               $time = mktime(0, 0, 0, $user->profile_birthmonth, $user->profile_birthday, $user->profile_birthyear);
-              $output .= form_item(t("Birthday"), format_date($time, "custom", "F j, Y"));
+              $output .= form_item(t("Birthday"), date("F j, Y",$time));
             }
           }
       }

- Sandip

Kjartan’s picture

Kjartan commented

That fix doesn't allow for translation of the month. IMO the storing of birthdays should be done outside a unixtime (see bug 1418) and prevent timezone shifts.

boris mann’s picture

boris mann commented
Version: 4.3.0-rc »

This is still a problem -- off by one error, where even if user timezone and server timezone are the same, birthday is displayed as being a day earlier. When editing in user account, date shown is correct.

Also related to this bug and commented on in the 4.4.0RC discussion here. Should be filed against 4.4.0RC, but can't select that option right now.

lba’s picture

lba commented

Maybe this is a bit too simple, but I guess using "12" as hour field to mktime would solve this bug for everyone except people in Nuku'alofa (GMT+13) (sorry guys ;-) )

Thus:
$time = mktime(12, 0, 0, $user->profile_birthmonth, $user->profile_birthday, $user->profile_birthyear);

Timezones are pretty much limited to GMT-12 or GMT+12... The world doesn't go any further...

Steven’s picture

Steven commented
Steven’s picture

Steven commented

I'm marking this as 'won't fix': this issue (along with other date-bugs) was fixed in 4.5, but required a whole different approach to the date field. It is very unlikely these changes will be ported back to 4.4.x.