After all of the work that was done to get the DateTime into core, for various reasons, improvements to the module didn't progress at the same rate as the rest of 8.0.x. As a result, there are some very old issues in the queue (I have triaged a lot of them), and there is some work that needs to be done both on the module and on date handling in core in general. Thankfully, I don't think there is anything that can be considered a release blocker (though we do have some bugs that can be addressed outside this issue).

The purpose of this issue is to (1) discuss what needs to / should be done in 8.0.x, (2) discuss future plans that need to be deferred to 8.1.x, and (3) discuss/track this in one place as a lot of it is interrelated and we can create child issues.

Core Features

Developer Experience (DX)

#2489476: [PP-1] Provide Views integration for datetime fields used as base fields (probably dependent on #2337515: Allow @FieldType to customize views data)

Investigate using Symfony 2.8+ Clock Mocking in tests.

User Experience (UX)

#2567815: Add week, date, and year-month Views argument plugins

Documentation

XXX

Testing

#2498619: Unit tests should use a default timezone other that UTC

#2497585: Simpletest should set a system timezone in setUp

Comments

mpdonadio’s picture

OK, I started out by adding two issues that fall outside the module proper, but are important. TestBot runs in UTC, which has been shown to mask some problems with TZ handling. This has been worked around in individual tests, but this should be done globally to catch any future problems. We may need to look into a similar issue for #2232861: Create BrowserTestBase for web-testing on top of Mink.

pjonckiere’s picture

As mentioned in #2122529: Add unit tests for the Date service, I think we should find out the parts where we need automated tests for. We could do that as much as possible in 8.0.x, since test-only changes are allowed during beta.

mpdonadio’s picture

Issue summary: View changes
webflo’s picture

Shameless plug, i wrote a small datetimepicker module which integrates xdan/datetimepicker with Drupal Core and the datetime field. This could be the successor of data_popup?

mpdonadio’s picture

Core already supports native HTML5 datepicker w/ backwards support via jQueryUI for browsers that don't support it (not 100% sure the time portion landed, though, have to dig and add it here if it didn't). What advantage would this provide? I don't really see a need for date_popup anymore, but could be swayed otherwise.

morenstrat’s picture

I just tested my first D6 to D8 migration and my date fields were not migrated. Is migration something that should live in the core datetime module?

tedbow’s picture

The datetime View Arguments don't take into account the user's timezone. That means that if you make a View that has \Drupal\datetime\Plugin\views\argument\YearDate argument then all users will same events even if the timezone for a user would push certain events into either the next or previous years.

This is probably an edge case for years but for the new arguments in #2567815: Add week, date, and year-month Views argument plugins would be more effect by this.

So if you used the FullDate argument then dates that would be in a different day because of the user's timezone don't show up correctly.

Am I right about this?

I will create a followup.

tedbow’s picture

arknoll’s picture

@mpdonadio I believe we should add to this the ability to select a timezone for the datetime field. This was part of the date module/date api in D7. I believe it makes sense to include this in core.

arknoll’s picture

Issue summary: View changes
arknoll’s picture

Issue summary: View changes
colan’s picture

Can we add a core feature here for 8.1.x to add an end date to date fields? I'm coming from #2161337: Add a Date Range field type with support for end date and #2492011: Port Calendar module to Drupal 8, and it looks like things could get extremely messy if start dates are handled in core while end dates are handled in contrib.

At the very least, let's get it added to the data structure / DB and then contrib can handle the UI. This is what we did for field translation in D7 with Entity Translation.

mpdonadio’s picture

#12, I do agree that end dates and recurrences (along with some of the TZ issues already identified) are important for fully functional calendars, but at the same time, the kitchen-sink version of the Drupal 7 Date module wasn't part of the vision when this was added to core. On the other hand, we need to make sure that core supports anything that contrib may need to do.

I am going to make some issues (maybe just another META issue) and try to get some time with one of the product or framework managers to talk about this, or at least get it on their radar to talk about amongst themselves.

colan’s picture

Issue summary: View changes

Looks like #2161337: Add a Date Range field type with support for end date is now a core issue, and it's got some movement. Adding to the list.

mpdonadio’s picture

Unless I get sucked into routing or views issues, I plan on plugging away at the DateTime issues at DrupalCampNJ (which coincides with Global Spring Weekend) if anyone is going to be there (I'll be there Saturday--Monday, and mainly hanging out in the sprint rooms), or if anyone wants to arrange some virtual coordination via IRC.

mpdonadio’s picture

Issue summary: View changes
swentel’s picture

Issue summary: View changes

Adding #2305073: D8: Date repeat feature requests - whether this is core is detable, we not a bad thing to track it.

jhedstrom’s picture

Issue summary: View changes

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

jhedstrom’s picture

Issue summary: View changes
webflo’s picture

Issue summary: View changes

Created an issue optional end dates. #2794481: Allow end date to be optional

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

ExTexan’s picture

How about adding the ability to specify granularity?

It would be nice to use a date field but have the user select only month and year. Such a feature should include the ability to specify defaults for the "unused" fields - for example: if I select month and year, give the option to populate day with first or last day of the month, that way the date itself would be complete and could be used to compare to other dates.

jhedstrom’s picture

ExTexan’s picture

Thanks for the link, @jhedstrom, but that appears to be specific to views filters. I'm asking for granularity on the field itself, as well as a default for the missing part(s) (as mentioned in the OP).

mpdonadio’s picture

#25, thanks for the clarification. We have several things we are trying to weigh here as we keep working on datetime/daterange in core. The primary focus is to provide stable, testable, base functionality, but still get all of the basics in core itselft. Getting daterange in was one step, and improving timezone support is another. The balancing act has to do with determining what is essential and what can be moved into contrib. Fields with lots of options are problematic, as they can cause lot of edge cases and make testing complicated.

It sound like what you are describing can be handled with a new widget on the existing fields. Drupal 8 makes this pretty easy. I would gladly accept a patch for this in https://www.drupal.org/project/datetime_extras We are handling recurrences in a similar manner.

ExTexan’s picture

Thanks @mpdonadio. I posted a feature request in the issue queue for datetime_extras.

ndlarge’s picture

Sorry for a possibly misplaced question, but is anything being done to accommodate dates outside the range of 1970-2038? A vanilla installation of the latest D8 won't let me store a date earlier than 1/1/1970.
Quite a few people have expressed a need to store and process historical dates in the last 10 years or so, and apparently placing the adodb date library in the date module directory used to fix the issue for D7 but it doesn't seem to work in D8, for me at least. Should we wait for some solution in the D8 core?

mpdonadio’s picture

#28, are you talking about created/update on entities (like node), or datetime fields?

Timestamps are limited to 1970-2038 because they are Unix timestamps, which have the same limitation.

Datetime fields don't have this limitation. I just manually tested this, and it works. Nearly sure we also have explicit test coverage to prevent regressions, too.

ndlarge’s picture

Thanks @mpdonadio and sorry for a late reply - I somehow missed your response.
I have a vanilla installation of 8.2.3 on Windows/XAMPP (if that matters).
I have created a new "content type", added a field chosing "Date" as a field type, then chose "Date only" as a "subtype".
When I'm adding a node of the new type and enter a date like "1850-01-01" it seems to save correctly, but when I view the created node, the date shows as 1970-01-01.

gambry’s picture

@ndlarge I guess is something wrong with your installation.
Just tested a date field on simplytest.me a vanilla 8.2.3 AND a date_range field on a local 8.2.3 (+ #2627512: Datetime Views plugins don't support timezones ) and I see the correct values (1850-01-02 and 1850-01-01 - 1850-01-02).

Can you debug your instance trying to understand the reason and if you find it's a drupal bug create a new issue and share the report.

Wim Leers’s picture

@ndlarge Please open a separate Bug report issue. This is a Plan issue :)

ndlarge’s picture

Sorry guys - I thought it was intended behaviour because I found a lot of similar complaints in the forums and elsewhere. If you tell me it's not supposed to work the way it works for me then it's obviously out of place here. Will investigate further and post a bug if necessary. Thanks for your time!

mpdonadio’s picture

#33, we have an issue #2795489: 2038 bug with PHP timestamps on 32-bit systems - warn users? but nobody has been able to reproduce it. If you can, please add to that one. Thanks!

agudivad’s picture

Hi Team, am having similar issue. When ever we enter the year before 1970, application saves as 1970 only. Have tested it in simplytest.me by seeing above comments, its working fine over there. So, am not able to understand the issue in my environment. Am testing it in windows system, could it be reason for this issue or please let me know the possible reasons

mpdonadio’s picture

#35, read the issue I linked. It's a 32 bit PHP problem. We need input from core commiters on we should proceed.

Gábor Hojtsy’s picture

Project: Drupal core » Drupal core ideas
Version: 8.3.x-dev »
Component: datetime.module » Active Initiative

Moving to active initative.

xjm’s picture

Yep, this is indeed an active initiative. Thanks Gábor!

yoroy’s picture

And maybe it's even done now? There's a few followups left, but most of #2788253: Plan for DateTime Range experimental module is done. Almost ready to mark a whole initiative as fixed? :)

mpdonadio’s picture

Issue summary: View changes

If we can wrap up #2786577: The Views integration Datetime Range fields should extend the views integration for regular Datetime fields, then I think we can say this initiative is essentially finished.

bahuma20’s picture

Issue summary: View changes

Updated duplicate issues

yareckon’s picture

I would consider #2794481: Allow end date to be optional and #2699895: Allow configurable date attributes to collect to be 100% core functionality (both are in the summary since forever ) , without which I would hope this initiative isn't considered finished.

The reasoning is that granularity of data input (even per field item) having an optional, but not required end date are completely expected features of a "Human Compatible" understanding of Dates and times. I understand allowing End dates to be made optional on DatetimeRange would obsolete Datetime, but I still think having a single field with this option is the best possible user/sitebuilder experience.

yareckon’s picture

@mpdonadio I see your argument against a do it all field here #2819459: Versatile date selection needs a lot of fields where you call it "unmaintainable". Alas, all the workarounds for limited core functionality are also "unmaintainable" for site owners, and so far contrib has not stepped in a with a separate widget. Where do we go from here?

mpdonadio’s picture

#43, we need patches against either of those issues to determine what the impact will be. I think the end date one will have more impact, at least initially. If that can get in, the flexible input parts one can be tackled in contrib as a new set of widgets.

We also need to get the field tests refactored into manageable chunks (each is about ~1000 lines long and takes several minutes to run locally). Optional end date will probably double the number of assertions needed in DateRangeFieldTest.

Of the people working on datetime issues, most are focusing on the two (or three) big views ones. Unfortunately, "they're both big and both at the intersection of two of the scariest subsystems" and have been in and out of RTBC for about a year. The TZ input one is on the heels of this, but blocked.

I am working on internal things, and REST related ones.

That means we probably need others to get involved work working on this.

jonathanshaw’s picture

The Tz input issue is blocked by needing input from @mpdonadio / @jhedstrom on its comments #127-130. I might be willing to move it forward (which would involve refactoring tests first) but more direction is needed.

GaëlG’s picture

Drupal 7 had an "All day" checkbox on date fields, allowing users to specify, per entity, if the date has a precise start time or not. It looks like this feature is not available in Drupal 8, and I could not find any issue about this. Did I miss something?

jonathanshaw’s picture

minorOffense’s picture

Hello

I have a client which may be interested in putting funds to have us (or the maintainers of the Date functionality) finish these improvements. They're looking to integrate some rather complex event management workflows and need repeating dates, end dates, etc.

Not sure how best to estimate the work left or how to distribute the work/funds but if someone could contact me directly that would be great.

dalra’s picture