pm_date picker sets day -1 on Jereons Profile Manager plugin


the problem is with a DOB field created in profile manager using pm datepicker
takes -1 from the day on dates before 1/1/1970.
e.g. 6th November 1966 becomes 5th November.
This is true even with the time zone is set correctly.

It was noted by Dhrup that
'…. mysql stores internally as the number of seconds elapsed since midnight Coordinated Universal Time (UTC) of January 1, 1970.'

it is a fresh migration of the elgg server and the problem existed before it was migrated

my Elgg hosting server is in California   - 7 hrs
I am in Sydney + 10 hours
elgg log browser showed - 7 hours, so it was initially working to California time as would be expected.

What I have done so far:

1.
set time zone to Autralia\sydney (+10) in \engine\settings.php
 Now I have set the TZ then I am just having the problem with DOB's before 1/1/1970 showing -1 to the day.
(I don't yet know how this will effect people in other TZ's filling in the DOB.)

2. using changes suggested by Jean Marcel on the profile manager plugin page
I added the code  below underneath the line $val = $vars['value']  in the file \views\default\input\pm_datepicker.php;

    if (!empty($val)) {
$val = $val + 28800;
    }


this kind of worked, only in as much as the DOB field being saved in Edit Profile, now shows the right date under the Edit Profle page, but after saving when viewing the profile it still showed the -1 day effect. (i.e. to anyone else looking at my profile it will be -1 day in DOB field)

3. Jean then suggested (and he noted it as 'un-tested' ) putting it also in the \views\default\OUTPUT\ pm_datepicker.php file. after line 20.
I did this  but it had no effect.

So I am back at the same place. and a little confused about the time zone phenomena and how setting it to Australia\Sydney will effect users filling their DOB in from other tz's. I am waiting for someone in CA to login to test it for me.

The site is the production site but hasn't gone officially live yet so I have time to make changes before members start to join in about a month.

  • The output view is using date() which uses the local time of the server for formatting the time. I'm wondering if switching to gmdate() fixes that.

    Other things to think about:

    1. JavaScript is probably inserting the date at midnight so a timezone issue will easily move the date back by a day

    2. I think the unix timestamp is being stored directly in the database as an integer so this should be independent of mysql

     

  • Problem has 2 edges - input(edit) and output (display)

    If properly patch fix the code for both situations ->
    both ends will work okie.

    Probems is caused by Date Input being stored incorrectly for
    Dates prior to 1970 the Epoch start - b/c the values become negative and
    so need to adjust accordingly - ther must be some error in the conversion from input time to storage time that causes this.

    I put your given date value -99572400 which *is 5th Nov 1966 at 13:00 GMT ( 1966 11 05 08:08:00 ) <-- if that is indeed on your database - then that *is the incorrrectly stored value.

    Here is screen shot of running your date thru my Util TimeStamp :-

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    image

     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    And the corrected Date for < 1970 

    -- using logic similar to what I believe needs to be coded into the date relevant Date Picker section

     

     

  • read that " 3 edges - input(edit), output (display), database storage ". ithink that the date is stored incorrectly.

  • thanks Dhrup I think you are onto something there, what you are saying sounds to me like an explanation.

    In the end I got so frustrated with it I went 'outside the box' and decided I didnt really need to know everyones birthdate anyway, and now settled for an age range selection field instead. which works fine for me and members, maybe even better. So no date picker problems now : )