Hi,

My server is running at +8GMT.

When I use the time field, it stores in the database OK - but when displayed in the grid view it is +8hours out.

So when I enter in 10:00 as the time - it stores it as 10:00 in the database - but shows as 18:00 in the grid view.

When I go to edit - it shows as 10:00.

This does not happen in the testing environment.

Possible, in facts.
Hold on.

Better now ?

I added the correct code in the save() function. It take in account the timezone.
Fixed.

It will convert to the SERVER-UTC all inputs, but also all the parameter recieved in the save() function.
It means if you do aIt will subsctract the user offset as well. At the moment it is not the best but I don't know where to put it properly. Maybe in the controller, but there is no standard for that.
I will do more investigations, maybe I will move it somewhere else in future.

FIXED BETTER NOW.

Avoid my previous code, it was wrong.
The idea is to user the 'USER_UTC' filter in the XML form definition.
It works also for Unix fields.

Hi Chef,
Is this something we do in cook builder? Or do we have to fork every form with a date field? (not so good)

Using the Stable release 2.9.3, the Cook builder, and on my +8GMT server - I enter in my date...



But it displays a day out in Grid View...



(to be continued...)

When I go to edit it again - it is now a day out in the edit form.



This would be confusing for most users using the builder.

I'm not sure why you don't use the server time.

Perhaps if you need too - suggest to use the Time zone in Joomla? Failing that - perhaps make a component option field for the time zone?

(My Server time and Joomla Timezone is set to +8GMT)

Thanks

(PS: can you please allow more than two links the forum post - so we don't have to break things up like this)

Sorry - I'm talking about Dates now. Maybe that needs a change too.

The Time field is also still broken. It is good on Grid view now - but when I re-edit the time - it becomes reduced by the Time Zone.

Actually, each time I click Save - the time is reduced by another 8hrs.

Cheers

Normal,

Database value (UTC) > Display (UTC +8h) > Save (UTC - > Same database value

You need to set up the admin timezone to UTC if you want to save the same hour/time.
Even for the dates it is important don't you think ? If a user is in the opposite of the globe what do you prefer with dates ?

It was the previous version which was wrong. Now everything is correct, but in your dataset you might have to reset the hours maybe.
Another possibility is to configure the SERVER_UTC to +8 Because the server itself can be different than UTC.

The most important is that you choose wich UTC you want to reffer the times, and then to always do the conversions at READ / WRITE.

You say : The time is always reduced by 8hrs when you save.
What time is displayed ? the USER_UTC, or the Database value ?

I did the tests with SERVER_UTC = UTC, maybe I should test to change the SERVER_UTC reference.

I am gonna test your project.

Perhaps use what Joomla does...
docs.joomla.org/Calendar_form_field_type

Joomla uses a filter for time zones...
Saving in UTC can add an extra complexity when it is not necessary in most of my cases.

Do you need an output from me? Just let me know what php code run.

I used the USER_UTC filter in the last fix.

Ok, I can put an option for that, and I think will only put it for datetime and time. Not for dates, because I was thinking that it is not really working.

Example
2016-01-01 00:00 +8 => 2016-01-01
2016-01-01 00:00 -8 => 2015-12-31
2015-12-31 00:00 +8 => 2015-12-31
2015-12-31 00:00 -8 => 2015-12-30

...and so on. So it is totally wrong.

In my case, I'm creating an event list - but there is nothing smart about these dates and time.

The user will type in a Date, Time and location of an event. It needs to be displayed exactly as what the user has typed - regardless of where in the world other people are viewing it.

So if the user types in "Sep 25th August at 10am in Perth" - the display will always show "Sep 25th August - 10am" - regardless of where you are in the world.

If I was on a website for a Paris Cinema, and looking for movie times - it would show me time in Paris time. There would be no UTC logic involved.

Maybe I should use text field instead.

(But there is still a bug with the UTC logic).

Yes, you are true.

I was thinking about 'creation_date', 'publish_up', etc...
For the server automations it is very important.

Do you experience a problem with times, still ?
I am fixing that right now.

Thanks Chef.

Take your time - I'll test it out tomorrow - it is 6:20PM GMT +8 = 2:20am in the morning here and I have to get some sleep

I must say, you are very good attending all my silly questions (and very clever).

Thanks

You are not asking silly questions.

There was some bugs. And your remarks are highly welcome.
Thank to you the service is evolving a lot. K++ ++ ++;
(I added a feature option, that I can announce now... lol)

It should be better now.
You will find a new parameter in the 'time' and 'datetime' field.
It is OFF per default. I totally agree with you, and if somebody wants it, he will find it. Otherwise it is too complex for a beginner who never heard about it.

So now, let's talk about the DST (Day Saving Times)... lol.
I am joking, but yes the work is not 100% finished because every country apply also a specific hour change during the year. In France, we are in summer time now.
I let this work for the future if somebody ask for it.

Is it better now?

Thanks Chef,

The Grid View is still calculating UTC for the Time field. See snapshots...

During New...



During Grid View... Note times are displaying +timezone.



When Editing - it shows the same time as New (which is good).

Also a typo in the Time Field tool tip - "Saves values in Universal Time clock, wich" - should read "which".

The "Manage UTC" setting is OFF for my time field.

I cannot see the "Manage UTC" setting for the Date field.

(2.9.3 build)

Cheers!

---

Folks here in Perth voted "no" to Daylight savings for two reasons - because we didn't want our curtains to fade and our cows don't like it
True story