Fix localized date time input #1795
Conversation
|
Fix for #1796 |
JoshHarmon
added
the
s:feedback
|
Any reason you added the feedback label here @JoshHarmon? (Also note that those labels should be added to the issue not the PR ;)) |
|
Was probably me interpreting the thing the label was for as something other than it really is. My interpretation was that feedback is for the verification/review/suggestions of/to a PR before merging. On Jun 21, 2015, at 11:46 PM, Jones notifications@github.com wrote: Any reason you added the feedback label here @JoshHarmon? (Also note that those labels should be added to the issue not the PR ;)) — |
|
Here's a list of labels and how they should be used: http://community.mybb.com/thread-153813.html :P |
JN-Jones
removed
the
s:feedback
| @@ -899,7 +899,7 @@ | |||
| { | |||
| $privatecheck = ''; | |||
| } | |||
| $start_date = explode("-", gmdate("j-n-Y-g:i A", $event['starttime']+$event['timezone']*3600)); | |||
| $start_date = explode("-", gmdate("j-n-Y", $event['starttime']+$event['timezone']*3600)); | |||
There was a problem hiding this comment.
Any reason time was completely removed instead of using the timeformat setting? Same applies to the line below.
There was a problem hiding this comment.
The date string that is generated by the gmdate() at these locations is immediatly split at the '-' characters.
Of the resulting array only the first (day of month), second (month) and third (year) elements are used in the code afterwards. The last element of the array (time) isn't used anywhere, therefore I removed it in all of these locations.
There was a problem hiding this comment.
Yep, only 0, 1 and 2 are accessed. @Destroy666x was there anything else or is this merge ready?
There was a problem hiding this comment.
I don't know, I haven't tested it and checked whether all time inputs are covered yet
|
Ok, whoever checks this then (don't have time to look at it atm) should also check whether the places where |
|
@Evenprime - can you please solve conflicts? It seems to be fine, at least for me |
|
This PR has merge conflicts that need to be resolved.This PR has merge conflicts that need to be resolved. |
Admin-CP announcements edit view Use $mybb->settings['timeformat'] in announcement preview in admin-cp Fix inconsistent timezone handling and time formatting in mass mails Data was read applying the systems timezone with the "date()" function, but was written and interpreted as GMT. Leading to "time leaps" everytime a mass mail is loaded for editing and immediatly saved again. Allow both "am/pm" and "AM/PM" like everywhere else as valid input Always use the 'timeformat' setting for time of day displays and input field presets. Avoid applying timezones twice by using gmmktime (GMT) and then my_date (respects timezone settings and DST of users) Respect Timezone and DST of the user settings for mass mail sending Fix starttime/endtime presets Respect user timezone and dst for delayed moderation input and espect 'timeformat'-setting for display of existing delayed moderations. Respect 'timeformat' for display of bantime selection box Respect 'timeformat' for bantimes selection box display Accidential commit The time part is not used, therefore don't include it in the pattern Announcement editing in ModCP respects user timezone and DST settings Whitespace cleanup
|
Squashed and rebased changes, fixed merge conflicts |
|
Just looked through and all looks fine to me. @Destroy666x see anything else before I merge? |
|
If you tested (not only looked through) it and everything works as supposed to - feel free to merge. |
Related Thread on Forum: http://community.mybb.com/thread-165257.html
The target of this pull request was two-fold:
Admin-CP Forum Announcement creation/editing
Admin-CP User banning preset bantimes selectbox entries
Admin-CP Mass Mail creation/editing
Mod-CP Forum Announcement creation/editing
Delayed Moderation
Admin-CP Mass Mail creation/editing
Mod-CP Forum Announcement creation/editing
Delayed Moderation (original reason for this pull request as mentioned in the corresponding thread)
(Admin-CP Forum Announcement creation was intentionally left "GMT" only, because there is a label that states that inputs are always interpreted as GMT.)
(The Calendar already offers to set the used timezone explicitely, therefore I didn't touch the logic there. I only shortened the time patterns at two locations, because the hour/minute part that is generated isn't used at these locations at all.)
Admin-CP Mass Mail added the current users timezone when saving data. If at all, the timezone data should have been subtracted at that point. This bug lead to strange behaviour, where repeatedly editing and saving the same mass-mail would push its delivery time further into the future (when timezone offset is positive) or the past (the other case).
Admin-CP Mass Mail would interpret "11:00 PM" as "11:00", because the matching for "pm" only checked for lowercase "pm". Everywhere else the same logic was case insensitive, now it is here too.
The function get_event_date($event) in functions.php would have applied timezones twice, if the server has a timezone/location set that's not "+0", because mktime is used where gmmktime should've been used (The correct timezone information is applied one line later during a call to "my_date"). This method seems to not be used at all currently.