Date element increments by 8 hours

[SteveRL]

I?m new to the component and I?ve installed a fresh 3.5.2 on my J!3.6.4 installation. I did fix bug with date string. Awesome functionality I?m having a problem with the date plugin in that the time sometimes increments by 8 hours. I get different (increment related) problems whether I store as UTC or Local. I?m not speaking about the default date_time, the problem is an element I have created called 'flight_date'. I am grouping and ordering by this element so it is effecting my list when the time increments. Come to think of it I shouldn't be ordering by this element but I'm still facing a problem in that it rolls to the next day eventually.

In UTC: Every time I update a record (via list form or inlineedit), regardless of what element I update, when I save, my flight_date element associated with the record increments by 8 hours forward.

In Local Time: When I copy a record, the copy is 8 hours in the future. Also, and maybe this is normal, but when Importing records, the time is 08:00:00, which is different from all other records which are 00:00:00.

Here is the current config of the flight_date element:
Show time selector: No
Store date as: Local Time
Format: Y-m-d
Default to current date: Yes
CSV Import: Normal
No Javascript / Evalcode / Validations

Related URL filtering Problem: I have a URL filter for now +1 day. It shows today and tomorrow correctly until 4pm, at which point it shows the following two days. I am in Los Angeles time zone which is UTC -8. Is there a way to base the URL filter of Local Time and not UTC?

 

[troester]

I can't replicate with your settings - but dates are complicated.
"inlineedit": AFAIK this plugin is deprecated and may be the reason for issues.

I can see in your profile that you are a member since 2011.
So:
Is this site an updated one (e.g. from J!2.5/Fabrik3.0)?

 

[SteveRL]

So that is a little misleading, I installed Fabrik on a different domain but the project never took off. I've really only started using the software in the last few weeks. So it's a clean install of 3.5.2. I tested on a dev site without inlineedit, no positive change. However, I have discovered something through trial and error. If I change "Default to current date", the behavior changes.

Default to current date = Yes
Adding new records yields 00:00:00, but every copy yields +8 hours

Default to current date = No
Adding records yields 11:01:01 (or whatever the current time is), copy doesn't change the time.

I'm grouping and ordering by 'flight_date', so I need every time to be the same (e.g. 00:00:00) otherwise the records within the day go out of order.
Contrary to my thought in the first post, it turns out ordering by 'flight_date' is important, otherwise the grouped dates are shown out of order.

Is this a bug or am I approaching this incorrectly?

 

[troester]

I can't replicate, with and without "default to current date" it's always adding time 00:00:00 (date set to local).
What is you Joomla time zone setting and your server time zone?
Do you have any other (non standard) settings in your date element?

 

[SteveRL]

Joomla time zone: Los Angeles
php.ini first line: date.timezone = "America/Los_Angeles"

I'm not doing anything non standard with the date element.

 

[SteveRL]

Another datapoint. After changing Joomla time zone to 'New York', a copy results in +5 hours, changing again to 'UTC', copy results in +0 (no change). Changing the date.timezone in php.ini has no effect.
So it works with Joomla in UTC but I'm sure there's a reason I don't want to run Joomla as UTC.

 

[SteveRL]

Any other ideas? I've noticed that after copying the record (which now increments the time +07:00:00), if I edit the record and click save, it resets it back to 00:00:00.

 

[cheesegrits]

I can duplicate some issues when copying the date, for dates stored as GMT. I'm fairly sure I know why, because the copy functionality runs all the elements through the submission process as if they were coming from a form (for reasons), and will be expecting the date to be in local time, and will remove the TZ offset when saving. Which is probably going to be a pain in the proverbial butt to fix.

I also noticed that when copying a date with no time specified, it's changing 00:00 to 12:00.

What I can't replicate is issues with editing. None of the dates on my Date Torture Test form get modified when editing and saving.

I'll have a hack at that copy thing. Might take a while though, as the date code is mind bendingly complex.

-- hugh