Datetime stored with wrong timezone

Status
Not open for further replies.

jcc

Member
J! 2.5.6
Fabrik - github Fabrik-fabrik-3.0.6.1-8-g526c8bf

This seems to be happening for all of my date elements, which seem to imply a system-wide type issue. The elements are set to store in Local Time (see image), but it stores UTC.

The host is set to America/New York
Joomla Server Time Zone is set to New York.
mysql is set to SYSTEM
php is set to America/New_York

Code:
mysql> select current_timestamp;
+---------------------+
| current_timestamp   |
+---------------------+
| 2012-08-24 11:49:09 |
+---------------------+
1 row in set (0.00 sec)

mysql> exit
Bye
[root]# date
Fri Aug 24 11:49:16 EDT 2012
[root]# date --utc
Fri Aug 24 15:49:18 UTC 2012
[root]# php test.php
PHP time: Fri, 24 Aug 2012 11:49:20
Save an account record (element from image)...

Code:
mysql> select last_update_datetime from account where account_id=1339;
+----------------------+
| last_update_datetime |
+----------------------+
|  2012-08-24 15:49:56 |
+----------------------+
1 row in set (0.00 sec)
Change element to Store UTC and...

Code:
[root]# date
Fri Aug 24 14:51:05 EDT 2012

mysql> select last_update_datetime from account where account_id=1339;
+----------------------+
| last_update_datetime |
+----------------------+
|  2012-08-24 22:50:59 |
+----------------------+
1 row in set (0.00 sec)

What am I missing!?!??? It is like Fabrik is taking the system time as UTC and doing the TZ conversion again.
 

Attachments

  • wrong timezone1.JPG
    wrong timezone1.JPG
    54.7 KB · Views: 420
That is bizarre, and I can't replicate it. I'm set up pretty much same as you, except on Central time. if I set up a date element with the exact same settings as yours, storing as UTC, I get the correct +5 offset. So I saved a record at 12:17pm local time, it saved as 15:17 (Central Daylight Savings, GMT-5). if I switch it to store as local, it saved at 12:19pm as 12:12.

BTW, how do your access permissions relate to the logged on user you are testing with? Should that user have write / read access?

-- hugh
 
Bizarre is a good word for it. While researching another issue, I found that the configuration.php conatins 2, seemingly related, entries:

Code:
public $offset = 'America/New_York';
public $offset_user = 'UTC';

I have a few sites and some have this setting and some do not. I think the difference is that the sites that were created using Joomla! 2.5.0 and were upgraded have the extra variable and those that created using Joomla! 2.5.6 do not. I can't find where this value is set in the back-end.

I have been unable to find much about what offset_user is supposed to do. So far, the best lead was comment in the Joomla! 1.6 code stream suggesting that is was removed because it was not used.

Anyways, I've tested with $offset_user = 'America/New_York' and there is no change. It is 08:30 here and, when set to store as local, the records are stored with 12:30 (which is UTC); when set to store as UTC, I get 16:30(-ish).

As for the privileges, They had been set to read/edit registered (and are again in my test list), but someone has obviously changed the settings on me. I have started that witch-hunt.
 
Hmmmm, yeah, I seem to have that offset_user as well:


PHP:
        public $offset = 'America/Chicago';
        public $offset_user = 'UTC';

So I don't think that has anything to do with it, as mine is set to UTC.

I'm out of ideas on this one. Will have to do some hands on debugging. Lets get that related data thing fixed first, then we'll look at this.

-- hugh
 
I know we were able to reproduce this yesterday and that you are also otherwise slammed.. Please update this one when you can...thanx
 
Yup. Thanks for your help in sleuthing this one down. I'll raise a github issue on this, so it doesn't get buried. Either Rob or myself will work on it as soon as we can, I know it's an important issue for you.

BTW, can you summarize the conditions under which you do and don't see that doubling of the offset? Was it for ANY hidden date element, or only ones that use the "always return todays date"? i know was I able to duplicate it here for that permutation, can't remember if I got as far as testing other date setups.

-- hugh
 
I'm not sure it is a summary per se

OK. I'll try...FWIW - I don't think anything in the 'Setup' below makes any difference, but I am including it for completeness. I hope this helps.

Setup: I'm doing my testing on a list that I created called 'tom test'. I created it through fabrik in the database that is the second Fabrik connection (i.e. not the J! database.) The table was created with the default id and date_time column; those have remained unchanged. All my testing was using the back-end interface to the list and form.

To my table, I added two columns. The (important, I think,) properties are identical except for Hidden:
Code:
Name: last_update_datetime
Plug-in: date
Hidden: No
Store Date As: Local
List format: %Y-%m-%d %H:%M:%S
Form format: %Y-%m-%d %H:%M:%S
Default to current date: No
Always return todays date: Yes
Show time selector: No
Time format: %H:%M:%S

Name: hidden_update_datetime
Plug-in: date
Hidden: Yes
Store Date As: Local
List format: %Y-%m-%d %H:%M:%S
Form format: %Y-%m-%d %H:%M:%S
Default to current date: No
Always return todays date: Yes
Show time selector: No
Time format: %H:%M:%S
When I insert a record (@ 2012-08-30 09:02:15 EDT), I get:
Code:
last_update_datetime:   2012-08-30 09:02:00
hidden_update_datetime: 2012-08-30 13:02:15 <-- This is UTC
Changing hidden_update_datetime to:
Code:
Default to current date: Yes
Always return todays date: No
Inserting (@ 2012-08-30 09:22:37 EDT) results are the same:
Code:
last_update_datetime:   2012-08-30 09:22:00
hidden_update_datetime: 2012-08-30 13:22:37 <-- This is UTC
Changing hidden_update_datetime to:
Code:
Hidden: No
Default to current date: No
Always return todays date: Yes
Updating (@ 2012-08-30 09:27:26 EDT) results are both correct (i.e. local time, though having the seconds set would be nice):
Code:
last_update_datetime:   2012-08-30 09:27:00
hidden_update_datetime: 2012-08-30 09:27:00
Changing hidden_update_datetime to:
Code:
Hidden: No
Default to current date: Yes
Always return todays date: No
Updating (@ 2012-08-30 09:35:48 EDT) and setting the hidden_update_datetime element myself results are both correct (i.e. local time):
Code:
last_update_datetime:   2012-08-30 09:35:00
hidden_update_datetime: 2012-08-30 09:35:00 <-- This is the value I set
I tried changing hidden_update_datetime to use the timestamp plug-in, but that is the topic for another thread as the results I'm seeing there seem unrelated.
 
right, think I have fixed this one. The issue was actually in the js code, where we were not creating a calendar for hidden dates.
The issue with that is that we are relying on the calendar js class to set the correct date/time in a mySQL format based on the element options, before the form is submitted.

This formatting was not happening and thus the data being sent was formatted differently to visible date elements.
 
If this has been committed to github, I will test in the morning with the others. Thanks
 
This seems to be broken again with Fabrik-fabrik-3.0.6.3-141-g325b6d4.

Correction: It is working just fine in this version.
 
Status
Not open for further replies.
We are in need of some funding.
More details.

Thank you.

Members online

No members online now.
Back
Top