Plan for Date 7.x-2.11 release

All child issues and php7 compliance.

+1 Just wanted to say that all the php 7 fixes could be in the 2.11. ikeigenwijs got ahead of me :)

+1 on this too
This patch already contains all the necessary fixes https://www.drupal.org/files/issues/date-n2533080-4.patch

When we are fixing PHP 7 bugs, please don't forget a PHP 5.3 critical bug #2873415: PHP 5.3 - Date field being flagged as Invalid date not actually invalid ;)

everything referenced for this release appears to be RTBC or FIXED except for one needs review #2995679: PHP 7.1 no longer converts string to arrays the first time a value is assigned with square bracket notation

I do not think 7.x-2.11 should be released before #998076: Problem with timezone handling (caused by date_get_timezone_db returning only UTC) is fixed. Mishandling timezones is a pretty serious bug for any site that cater for users in different timezones and allows the user to set their own timezone.

The only way I am able to use Date now is to set site's timezone to UTC and not allowing users to set their own timezone.

Is the current 7.x-2.x-dev worse than 7.x-2.10 when it comes to time zones? If not, the release should go ahead. We need things like PHP 7.1 compatibility.

Is the current 7.x-2.x-dev worse than 7.x-2.10 when it comes to time zones?

No.

I've spent the best part of this week trying to get to the bottom of the timezone handling in Date as it was blocking an important project. Handling of timezones is not done right, but as far as I has been able to tell, exactly the same bug exists in both 7.x-2.10 and the latest snapshot, so releasing 7.x-2.11 with this bug will not make things worse.

I initially tried to fix it, but stopped digging when I discovered a workaround (i.e. disable timezones for both the site and all users).

I can live with this workaround, so if you really want to get 7.x-2.11 past the gate, disregard the plea I made in #8 and move forwards.

PHP 7 compatibility is becoming a serious issue.
As at least Acquia are requiring PHP 7.1 as minimum version per October 1st.
At the moment this means at the minimum pushing a dev version to prod.

Would it be possible to release 7.2.11 this month and bumping some of the pending issues to 7.2.12?

@botris, it would probably be reasonable to expedite the release of date for the reasons you mentioned in comment #11.

When it comes to maintaining contrib modules Damien McKenna has been more than carrying his weight! He is maintaining more modules than I can count.

If you feel the need to give back to the community please ask Damien for co-maintainer responsibilities.

Otherwise generally:

Here is how:

1. Contact all the current maintainers asking for maintainership, this is the first step and if it works you don't have to do the next step
2. If no answer from the current maintainers, open an issue in the project ownership queue.
3. Link the project ownership issue to this issue and mention that you've already contacted the maintainers
4. Also mention why the urgency (module needs compatibility with php 7.3.x , or other reasons) might help expediate the request.

Then @dddave will evaluate and likely grant you maintainership, then you will be able to commit this patch and tag and publish a release.

https://www.drupal.org/project/projectownership

For clarification, review this page https://www.drupal.org/project/projectownership

@joseph.olstad I think there is a lot of questions about release dates etc. in the issue queue's and people should be able to ask about a release date. Become a co-maintainer is not replying to my question, and I think taking on co-maintainer repsonsibilities of a top 10 Drupal 7 module only so you can release a new version is irresponsible.

Thanks for the update @DamienMcKenna.
All child issues are either RTBC or closed (fixed) except #998076: Problem with timezone handling (caused by date_get_timezone_db returning only UTC). But if the focus of 2.11 release is PHP 7 compatibility then I think it's ok to proceed as #998076 is not a PHP 7 issue.

As the one who added that issue (and now I am not allowed to remove it), I agree.

"RTBC" ?

I think the question was "is the new release ready to be created now?"
Since the last issue is postponed ;)

(Actually, I really hadn't heard of the acronym before...)

Ha, ok :)
@damien Is the new release ready to be created now? Would be great to have this PHP7 ready date module !

Tagging 7.x-2.11-beta1 might help to focus and spur the testing.

@DamienMcKenna

I'd love for folks to help test the current -dev snapshot

, what exactly do you want tested? Asking as all child issues are either committed to dev or in rtbc.

Thanks for the beta, very nice.

Do we plan to address "all" or could we release as is? Just reviewed #3032391: Empty date fields are being displayed and are currently testing it on PHP 7.3.x to make sure it works as expected.

Bumping this again. Have been running manual tests. Looks OK too me. No data goes up in smoke and I do no think we introduce any bugs that is not already there. @DamienMcKenna btw. that you for rolling the huge Views module update. I feel date could do with a re-fresh. Anyone see any release blockers?

Edit: I feel that most of the noice in the issue queue is timezone related. Initative #3012904: Plan for overhaul of time zone handling run by @gisle is suppose to address most of them. Progress of this work is unknown to me.

Feel #3016390: Change in "All day" end-of-day definition broke existing data belong in this release

@DamienMcKenna, could you provide an updated list of open issues that are preventing a 7.x-2.11 release of Date so that we can focus our effects accordingly? I agree with @steinmb that #3016390: Change in "All day" end-of-day definition broke existing data should be fixed before hand.

I have been tracking Date module issue queue for almost a year and I think #3016390 is the only show stopper. The rest is older issues that been around for years that we can tackle in a follow up release. PHP 7.2 and 7.3 should be fully supported and we should make sure it is.

The latest date module works well with php 7.3.x and as far back as php 5.3.x
It would be nice to resolve #3016930
Have not yet noticed any other regressions and this on two of my clients installations.

@steinmb @joseph.olstad, Thank you both for helping to maintain and monitor such a complex module. What about #2473171: Date and time formatter shows only current day in View and #3022337: ajax error when setting "custom" with plain format? Should these two issues be removed as children of this parent issue?

I think it is fine to ship without addressing those two issue. We could create a 7.12 meta issue and move them there so we do not loose track of them. As soon as we ship we could have a look at https://www.drupal.org/project/issues/date?text=&status=8&priorities=All... there is a lot of patches that we could roll into dev.

I would like it if #3032835: Validate input to date filter handler was included, as not having it can cause fatal errors on invalid input.

I just RTBC'd #3084897: Fix the LICENSE.txt so that now leaves #3083277: Implement hook_field_user_import_supported_alter and #3016390: Change in "All day" end-of-day definition broke existing data

There have been 51 issues fixed up until now. Are the following 4 issues the only remaining blockers to the 7.x-2.11 release?

#2473171: Date and time formatter shows only current day in View
#3016390: Change in "All day" end-of-day definition broke existing data
#3022337: ajax error when setting "custom" with plain format
#3083277: Implement hook_field_user_import_supported_alter

out of those 4 , I'd say that the only real blocker would be #3016390

with that said, beta3 is way better than 2.10 (52 fixes since then, as you mention)

beta3 is working great for me. No errors and resolves issues that were occurring when sorting columns on the default view.

seeing as 2.10 is php 7.2 incompatible , nor 7.1 probably, has 52 more bugs, why not just tag and release 2.11 and then reflag these issues for 2.12-beta1 ?

I agree. The only people who need a fix for #3016390 would probably be people who updated to the beta1 version in production. The issue was reverted, so everyone else would like a release, I'd think.

Is [ #3016390 ] a duplicate of [ #3096720 ] ?

if so, I think we can close [ #3016390 ] and cut a 2.11 release?

What can be done to help get 2.11 out the door?

Now that Ubuntu 20.04 is out I have started testing migrations of some Drupal sites to PHP 7.4 which is requiring many patches. Would be great to get a release out to limit the number of patches needed.

@Kevin Morse - Only one blocker left. #3016390: Change in "All day" end-of-day definition broke existing data Any help there would be highly appreciated.

I encountered #3009740: PHP 7.3 compatibility on a D7 site after a PHP 7.3 update, so I'd like to help get the release out.

I'll take a look at #3016390: Change in "All day" end-of-day definition broke existing data and see if I can fix it and unblock the release.

The fix that went in for #2016787: Far dates causes PDOException 22003 is going to break on sites not using the field_sql_storage backend. I've raised this in #3163293: date_update_7007 will fail with different field storage backends. and would humbly suggest that getting the trivial fix in will stop much pain for people upgrading and then more pain for the maintainers explaining that there's an issue with the release etc. etc. etc.

I think this issue #3163868: Datetime (only time) is broken can be blocking for 7.x-2.11

I don't think that issue should block the release of all the fixes already committed.

you're right, but we should write somewhere that, in specific cases, is still not compatible with php 7

Thank your for bringing the issue to our attention though I do not think #3163868: Datetime (only time) is broken is a blocker. There been talk/plans/work on re-doing the timezone but nothing have happen for a long time there. Have a look at #3012904: Plan for overhaul of time zone handling - Feel free to jump in there. My understanding, without looking into it, is that the timezone handling is a little brittle and perhaps lack tests.

@Steven Jones I personally see no problem that [##3163293] is part of 7.x.2.11.

@steinmb thanks for the link to the #3012904: Plan for overhaul of time zone handling, I hadn't found it and I find it very interesting.

As for #3163868: Datetime (only time) is broken in reality the problem is not the timezone itself, but the offset difference between the year 0 and the current year in the same timezone (compared to UTC).

The date module suffers from the problem because it uses the date 0000-01-01 for "time only" datetime, but the differences in behavior depend on the updates made in the various versions of PHP

Yeah, the PHP versions and workarounds in the date module goes way way back by the look of them. If I could had it my way: As soon as we roll 7.x-2.11 we could branch of to 7.x-3.x and in that branch bump the minimum PHP version to 7.x. and allow us to dump a lot of legacy code without worry about braking older PHP versions though I am not one of the maintainers and not a dictator :)

Just an FYI that the EOL for PHP 7.2 is this December, so it would be a good idea to get a release out with the PHP 7.3 compatibility fixes before then.

Hi there! Is there any update on this? Thanks!

@Sseto - There is only one blocker left and @DamienMcKenna have been doing great work the last days. Head over to to #3016390: Change in "All day" end-of-day definition broke existing data if you can. The sooner we fix it the sooner we can roll a new stable release.

Sorry folks, a little confused here. If I have not updated to any of the 2.11 betas I can move from 2.10 to 2.11-rc1 and not need to worry about #3016390?

@jackfoust I don't think so. The commit that caused the issue hasn't been reverted, because it did fix something else, I think.

+1 for releasing 7.x-2.11.

I suppose. Is there a quick and dirty PHP or SQL query that can be used to tell if a site is using the "all day" functionality?

For example, if I have the Date All Day sub-module enabled but am not sure if it's actually used anywhere, how do I find out?

yes please, release it as-is.

-1 My problem by releasing is that I fear that the whole day function then will "never" get fixed. I would be OK with a broken release if I could tell my end users, yes we know whole day is broken, and, yes we are going to address it within x-weeks. But since we all are volunteering our time, do we know this?

+1

My reasons for +1

1. We want our recommended release of date to support the recommended version of php
2. for those upgrading from rc3, they won't have an issue
3. all new data will have the correct all-day value,

Reasons for -1

1. historical data might not have correct all day value if upgrading from pre-rc or 2.10
2. some don't care about supported php versions because they have vendor supported legacy php with backported security fixes

Put a note in the release notes for those that might not be running rc3 already.

Somethings can be fixed now, they have had time to marinate. Others still need work and who knows when you and others will have time to vet them to a ready state.

+1 🚀

Another reason for -1:

The Usage of 7.x-2.10 is ~200K, but the usage of Usage of 7.x-2.11-rc1 is ~7500.

The sites that are penalized most by the upgrade are the ones keeping to stable releases, which is most of the sites using the module.

Keep in mind, if a site is already on the beta/rc versions, then they don't really need the next release all that badly, because they already have the PHP fixes.

w00t!

Is there any way to revert to 7.x-2.10 ? Or to handle things until 2.12 comes out?

Thanks,
Eric

@aitala, we reverted to 7.x-2.10. It takes some effort but certainly can be done. See my post here: https://www.drupal.org/project/date/issues/3203139#comment-14027666