[META] DateTime Module Improvements

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?

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?

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.

add #2627512: Datetime Views plugins don't support timezones
to other section

@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.

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.

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.

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

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

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.

re #23 that's over in #2749483: Datetime views filter plugin should allow granularity to be configurable.

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).

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

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?

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.

@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.

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

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!

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

Moving to active initative.

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

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? :)

Updated duplicate issues

I would consider #2794481: Allow end date to be optional and #2699895: Add settings to define #date_increment for datetime and datetime_range 'default' widgets 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.

@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?

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.

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?

@GaelG that is probably related to #2699895: Add settings to define #date_increment for datetime and datetime_range 'default' widgets

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.

Adding #2942828: Make the Date and Date Range configurable to allow MIN and MAX dates, only past or only future dates, or both to Core Features.

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?

@GaelG that is probably related to #2699895: Allow configurable date attributes to collect

Not quite.
This is a user-facing option: as someone creating a date field, i want to be able to click an "all day" checkbox, so that the time can be optional.

So, the field must be *able* to collect the time, but it must be optional.
In D7, I believe this was accomplished naively by reserving the time 23:59:59 to denote that the time value is not relevant.
Is there an issue open for this?

Adding the closest related issue I could find to what #50 is asking for. I don't feel empowered to directly add it to the list in the IS, but someone else should feel free to move it if it should be considered part of this plan/initiative.

Thanks,
-Derek

I'm not sure if this belongs here (or as a child issue of this particular issue), but figured I would mention the other closest issue to #49. Please feel free to remove it if it should not be a related issue.

#2734255: Support a per-instance "all-day" option for datetime and datetime range fields is even more related to #50.