Hello Jackson,

I am really sorry for the delay of this reply as it is a weekend for us here. Can you download the attached file and upload it into /components/com_easysocial/themes/wireframe/albums/ and see if the problem still persists?

Hi Mark,

I copied form.php over to the folder you mentioned above and one thing I noticed is when I edit an Album it does show me the Date that is displayed in the Album and not like before it reverts to the current date but it still 1 day off the date set.

Please check site details optional info where to try.

Thanks

Jackson

I can confirm this issue as well. The date goes 1 day back and it resets upon editing the date when editing the album again.

Hello Josh,

Can you please provide us with the back end and FTP access to test this since Jackson cannot provide the FTP, it would be much appreciated if we can have the FTP access to debug this.

Admin/FTP info attached.

Hello Josh,

How do I reproduce this issue eh? I tried setting the dates to 4th April, 5th April and also 25th May, they all appear as it is for me

It turns out the time zone issue is the reason behind this issue. When I use the universal time for my profile, the date is correct. Unfortunately when I set the global time zone in Joomla's configuration to Los Angles (-8), the album date ends up being one day behind. This is probably because EasySocial is ignoring the admins selection of the time zone and using the Universal Time. So what I recommend is for ES to use what the admin specifies in the Joomla Configuration.

As for the date reset, this issue exists regardless of timezones. When you set the date, it puts it in. But when you go back to edit the album, it sets the date to the publish date which the author has to change the date again.

Hi Josh,

I'm also in LA and I tried this, not working for me but the new form.php that Mark attached fixed that issue with Date when editing reverting to current date instead of what the date that was previously set to. At least in my end, it's just in my site it still displays -1 day after saving.

Josh, are you talking about the Timezone in ES User Profile? I don't see a selection choice for Universal Time, I can only see that in Joomla Configuration which I already set to Universal Time.

Thanks,

Jackson

The fix worked for the editing date issue (when replacing the file Mark suggested). Hope that fix gets included in the next version of ES.

As for the -1 day issue: You probably set your profile to LA time. The good news is that ES stores the created time the same regardless of time zone! I was really worried about this until I looked at how Joomla and ES stored the values which they do it right (articles and albums do it exactly the same). The "assigned_date" column however is debatable depending on the intentions.

So the problem is that ES factors in your time zone when reading the assigned_date, for example in the Database an album of mine is set to "2014-04-14 00:00:00" (posted from the Los Angles Time Zone). But the album itself says "13 April 2014" when viewing it because it subtracts the 8 hours from "2014-04-14 00:00:00". ES reads the date relative to your profile/site settings and the assigned time stamp in assigned_date rather than my old prediction of using Universal Time.

I have two solutions to this issue (note that the db tables mentioned are from 'jml_social_albums'):

1. Best Option in my Opinion: The albums should literally read right off the assigned_date (column) time stamp and ignore your timezone when displaying on the album (but not ignore your time zone when posting). So if I lived in Malaysia right now and posted an album, it would say April 15th. If I posted a new album in Western America, it would say April 14th. If I view the Malaysian album from Western America, it would say April 15th even though it's April 14th here. This is perfectly okay because even though it's "in the future", it's giving us the real time of when an event took place.

With this solution the storage method for the value is 100% perfect as of right now. The only thing that would need fixing is to remove the timezone relativity (as in ignore your timezone for the display date). This method is also good if the author explicitly says "On April 15th I did so and so". It would be silly for it to say April 14th.

2. The assigned_date data should work just like the created column using hours, minutes, and seconds. So if I post an album in my time zone at 6:58 p.m on April 14th., it should store the value "2014-04-15 01:58:23" and then rely on my time zone choice to bring it back to April 14th (considering I have it set to -8 Los Angles). This method is great for making albums relative to me in a time sense, but it is not literal in the sense of how we document time in the real world.

I had to think this over for over an hour until I figured out the two best methods for going about this issue. Either time needs to be literal or relative to people.

Thanks Josh, I have applied the fix on the site This will also be fixed internally.

I'm curious which method you chose for the timezone issue.

I agree, it should display the date of whatever is saved in the db and pre-populate date input according to Profile Time Zone settings. One suggestion Mark, to make ES intelligent, if possible ES will check User's Time Zone setting, it set then use it, if not then use Joomla Time Zone.

Jackson

Actually it does check the users Time Zone setting, and if not the user, then Joomla's. I was mistaken earlier in this thread when I assumed that the Universal Time was to blame which it actually isn't. This is actually why we are having this issue (time zones changing from the zeroth hour). To see how ES stores the album time data go to:
Your Host's cPanel > phpmyAdmin > Database your using > 'jml_social_albums (your prefix may be different). You should see how the time is being stored, assigned_date is the column we see on the album. This is where I got the proper evidence to realized that ES is not actually using it's own time, it's using Joomla's time.

This is where we have to make a choice between two options. Do we want an absolute date (as in the date that a history book would record) or do we want the date relative to your time zone? This post goes in depth with the two scenarios. Unfortunately we cannot have both an absolute date and one relative to the user (this is literally impossible by physics standards). The good news is that we can have a healthy compromise method. The date can be relative to the poster so that the person posting it has their date set rather than the users. So for example if Mark posts an album on April 15th of his time (ours being April 14th) it could say April 15th. If we post an album now using our time, for him it would say April 14th. While at first glance that sounds bad, from a historical stand point this is 100% accurate. But with a relative time to you method, it's actually historically wrong.

Here is a fun example, if Mark posted some firework photos of New Years on January 1, 2014 at 1 a.m., it would be kinda silly for the rest of us to see it as December 31, 2013. No matter how you dice up the time zone display (relative method), your always going to end up with that scenario. However with the absolute time method, it would be spot on. And because the absolute time method is relative to the poster, if I post my new years photos many hours later on January 1, 2014 at 1 a.m. Los Angles Time, Mark could still see it as the proper time no matter what! This is a good thing which is why in my honest opinion the album display of the date should ignore the user's/site's time zone, but not ignore the time zone when it's time to put in the date for the poster.

Hello Josh,

Hm, I am a little lost here. When storing the date, EasySocial doesn't compute any offsets. The problem earlier was because during the output, we try to compute with the offset and that is why it's displaying an incorrect date. After making the changes on the site it displays the date correctly already.

Mark wrote:

The problem earlier was because during the output, we try to compute with the offset and that is why it's displaying an incorrect date. After making the changes on the site it displays the date correctly already.

Exactly! The offset was from Joomla's timezone. I was confused earlier in this thread (before I made my lengthy post) and thought ES was using Universal Time until I actually looked into the database. So the fix you applied makes it work pretty much exactly how I would want it. The only problem is that when you go to edit the album again, it goes back 1 day. Is this caused by the offset upon editing?

Hello Josh,

Can you try downloading the attached file and upload it into /components/com_easysocial/themes/wireframe/albums/

Unfortunately my ftp acted up really bad (my host's site wasn't even loading when trying another method), which I accidentally deleted the form.php file. I downloaded the one near the start of this thread and of course placed in the form.edit.php file just now. I still have the same role back 1 day upon edit. Keep in mind this might be because my form.php file. This post has my ftp info. Feel free to replace the two modded files into /components/com_easysocial/themes/wireframe/albums/. I personally placed it in, but I don't know if you made changes to the form.php file since the beginning of this thread.

We'll update this in 1.2.8

Sounds good. I really appreciate the fixes.

Josh, I just had another thought and would like to send it to you now so you could quickly test this so that we are sure 1.2.8 is free from this issue. Can you download the attached files and upload them into /components/com_easysocial/themes/wireframe/albums/ ?

It still sends me back a day upon editing the album after replacing those two files.

Basically setting a date initially works perfectly. It's when you edit the album again when it does this.

Okay, looks like I missed one more file Fixed for good now

Awesome. The album issue is officially solved! Good work Mark.

Hate to bring you another issue, but now I see the same issue occurs with photos. The individual photo issue is exactly the same as how this problem started. But now that you know exactly how to fix it, I assume this wouldn't be too much work to fix.

Noted, thanks for noticing this Will fix photos as well.

Thank you both!

Mark, can I have the fixed files so I can test it too?

Jackson

Sure thing Jason. We all want ES to be as solid as possible, especially in the beginning. As for the files, I am not 100% sure what files were changed.

If it makes you feel any better I too have to wait until ES 1.2.8 for my main site to get this upgrade (Mark fixed my test site).

Hey guys,

Just checking back if everything is okay with the "edited dates" on 1.2.8 ?

Hi Mark,

Yes! It is fixed in my end

Mark, I just have one suggestion if you guys agree, when clicking Done, since it takes a few seconds before the screen refreshes while it's saving maybe the animated status should be in the middle of the button to tell the user that it's doing something. I actually tried to click Done several times thinking that its not doing anything.

Thank you again!

Jackson

The date issue is officially resolved. I tested this again just to make sure.

Jackson is right that there should be something to indicate that it's saving. I suggest having the check icon in the "Done Button" change temporarily to the loading icon.

Thanks for the heads up on this, logging this into our issue tracker