Allow value 'present' in the to field

there are many cases when this is "mandatory" feature.

for example in the instance of a (period) date to have a setting for end date value : "if left empty use present"

This would require a significant effort. I'm not sure it's even possible for this to work. Someone would have to at least provide a proof of concept patch to show how it could be done.

Variants

1. As i said in the previous settings, an instance setting for the End Date, if left emtpy use Present formatter, could be also an extra text filed for the text to be displayed to mean "Present" date&time

2. An "Use present date(/time)" checkbox for the End Date near its input form field.
If it's checked the End Date will not be used even it has value and the Formatter of the Date field will display a text that could also set in the field instance.

i think the second will a more complete solution.
any other suggestions?

What values would get stored in the database? What happens in Views searches or Calendars if those values are missing? I think calendars would not work at all. All the validation would have to be rewritten. All the views handling would have to be rewritten. There is much more than figuring out how to display the date.

i don't think i have the answers at this moment, but i think if a solution proposal it's "choosed", it will be easier to be implemented.

1. At this moment if i won't fill the End date, it will autofill the End Date with the Start One without have such setting for the Date field or asking me about this.
So is this could be considered a bug for (End) Date?

2. let's imagine a work experience case that imho could be a very common case for this feature.
In this case i can see that the End Date input form and its alternative to Present option.
So maybe to achive this:
- to have null value for the End Date equivalent with Present option checked
and/or
- to have another column in the Date field table, for present
For sure in both cases some reworking for handling those cases are needed.

You will end up with a database that has the same date as the start and the end. When you search for those dates using views, they will all be in the past, none will show up as current. I am not worried about how to make the form work, that is the least important part of the problem. The problem is what values are you going to store in the database and will those values work in Views. And so far all you have is a date with the same start and end date which doesn't begin to represent an ongoing date, so they won't. Unless you start addressing that part of the problem there is nothing we can do with this.

then let's clear the empty End date value.
Why it's filled with the Start Date if it is left empty?

Storing a bogus value in either field is not going to work. It doesn't matter if the bogus value is an empty value or if it matches the other field. Whichever way you do it you will end up with values in the database that don't represent the right time period. There is no way to query the database unless it has the correct values in it and there is no way to store the correct value if it is a moving target ('present').

If you can't produce code that will create a searchable database that works with Views, we can't do this. If you don't know how to produce such code (I sure don't), there is nothing I can do with this issue.

@KarenS, can you provide an answer at my question (#7) please. thank you

@JustMagicMaria sound interesting, could be an alternative. thank you

@vasike I have been answering your questions. I don't think this is doable. If you think it is provide a patch.

@vasike, the answer to #7 is long and complicated. But, here is an issue that does discuss some of that: #874322: To Date & All Day Date Handling.

There have been numerous requests for date module to store values other than complete dates in the date field. Examples include 'All Day', 'current', 'present', & 'TBD'. To be clear, this is likely to NEVER happen.
The reason is that date module relies on the date functions of PHP & MySQL (or Postgress, etc.) to store date values to a *DATE* database field type. PHP & MySQL both EXPECT a proper date for that value. They will not allow any other value to be stored to that field.
If date were to use a more generic field type to store values other than proper dates, it would introduce a large performance & code size penalty as the PHP & MySQL functions can no longer be directly leveraged.

The ONLY reasonable way to address these issues, IMO, is to add or attach another field to a date field to indicate things like 'All Day', or 'current' or 'TBD'. And this is exactly what is being discussed over at #874322: To Date & All Day Date Handling for the 'All Day' scenario.
Another option is that another module might be able to associate an additional field to a date field in order to specify 'current' or 'TBD.' Sounds like JustMagicMaria has even done this using CCK & conditional fields (no extra module necessary).

Personally, I fully support adding an 'All Day' flag, but I do not support adding a 'current' or 'TBD' value. IMO, those are more specialized use cases that do not fit with the overall scope of the date and calendar modules (date is primarily used for calendars)... how would 'current' be processed for display on a calendar page?

thanks a lot for the answers.

i also thought about using a NULL value for the End date and a flag column.
As the All day could be used for events, the Present option also could have "some" uses:
- "Life period" (birth/death dates)
- Work Experience
- Education
- Car Models for Auto Parts
- and probably many others

I'm going to try one more time to explain this. Storing NULL in the database will create the wrong results in Views. Storing the same date in both the start and end date will create the wrong results in Views. Adding a flag to indicate that the end date is 'present' will not be any help in Views. Nothing that has been proposed will work to create views queries that will return the right results.

This is not the same as the All Day flag. In that case we know the date and have stored it and we can make an assumption about the time (midnight). So we have a totally valid date and it will work in Views. With the 'present' option we cannot make any assumptions and we can't store a useful value in the database.

Unless someone can solve the problem of how we could ever retrieve the right values using Views, this feature is a non-starter. I've said that several times now and no one is listening, so I'm done saying it.

And I'm marking this postponed until someone can propose a solution that will work in Views.

Marked #405330: To Date always set to current date & #1413918: to date = current, present as duplicates of this issue.

I'm not suggesting that this is anything other than dirty/kludgy/hackish solution BUT... one possibility would be to update a date marked as "present" on cron. Every 10 minutes (or whatever) the value would be set to NOW().

This would ensure that the value is always correct in views AND the display can be easily changed to t('Present')

Solution == proposed :)

I too was hoping for this feature.

I have decided to go with two text fields. Start and End.

Hopefully I will never have to sort by start date or add this to a calendar.

No recent activity on this thread, overshadowed by Drupal 8 ?

Here is a possible solution.
Since the Date input area is already a fieldset with checkboxes for 'Show To Date' and several methods of input, could you add a 'to Present' checkbox? This checkbox would set the To field to the current day (one of the already available default values) and the heavy lifting would be done by the formatters. The theme layer would have to check for that To Present box and use text instead of the value of the date field. Since there would be a date available in the field, items like calendars would not crash, but for displays like a "resume" content type you could still have the 'to Present' string displayed?

A little heavier solution would be to have the checkbox, and instead of using cron as suggested by #17 you could update on node_load or other field access?
When( field going to be viewed ) // using node_access hook and view field handler
if('to Present' enabled on this field)
node->to-date = now();

I needed the same feature - ended up using Javascript on the client-side to alter the output of my view.
Search the DOM for those elements where the start date field and end date field have the same value, and change the end field to display "Present".