Allow "fuzzy" granularity

Marked #259702: Representing inexact historic dates as a duplicate, in which whereisian had posted

I'm not sure if this is a feature or support request.

I work with humanities researchers and deal with a lot of dates represented in inexact terms. Sometimes they are centuries, quarter centuries, decades, year range, etc.

With dates2, I can now represent historic dates more easily, but I am still unable to have one field handle several levels of granularity. For instance, some nodes will a precision to the day, other to the year, others to the century. When I try and enter a year range with a granularity of y-m-d, the dates are stored with a seemingly random value.

The work around seems to be using the a precise date range to represent an unknown period. So to represent a century, you'd enter say 1800-jan-01 to 1899-jan-31. Is it possible to allow some date fields to be blank?

Circa dates can also not currently be expressed. It occurs frequently that only one date of a range is known, such as an unknown birth date, but known death date. Would a checkbox to represent a 'circa' date be implemented?

Any comments are appreciated.

Cheers

There have been a number of request for this, but, as you noted, it's not that easy to do. It's not at the top of my todo list, but if someone needs it and creates a patch, I'll look at it.

Marked #262646: Empty/Incomplete dates as a duplicate of this request.

I'm going to mark #148118: 'variable' granularity with '00' padding as a duplicate of this as well.

Marked #271680: Dynamic granularity as a duplicate, in which phayes suggests "having the date system parse the input to determine granularitry. It would require an extra column that defines the granularity in the database structure."

Should be version 6, not version 7 :)

The need for "fuzzy" granularity has come up several times for me recently. Would love to see this feature. Thanks to all the contributors to this module; wish I had the skills necessary to write this patch.

this is an interesting feature request. i don't have time to work on it at the moment, but i'd like to see some more use cases for this to get a better sense of the full requirements. the cases reported in the requests above are a good starting point, but i'd like to hear more about edge cases like the need for historical "circa" dates.

Marked #134820: Allow variable granularity on date/times as a duplicate, and changed version per KarenS in that issue.

subscribe

Marked #311540: Allow year OR year+month OR year+month+day as a duplicate of this feature request.

michaek:

this is an interesting feature request. i don't have time to work on it at the moment, but i'd like to see some more use cases for this to get a better sense of the full requirements.

I want to create a chronicle of past events.
So let's say, an association celebrates bicentenary. Documentation was not good all time. So it is not exactly know, on which day the association was found; only the year is known:
1800: foundation of the association
The next known event is the first mention in a local newspaper, here the exactly publishing date is known:
1800-07-23: mentioned in local newspaper
The managing committee changed later, but the exact day is unknown, it's only proved, that this has happened at the yearly association meeting in december:
1801-12: new managing committee

So, maybe we get something like:

• 1800: foundation of the association
• 1800-07-23: mentioned in local newspaper
• 1801: relocation of the association office
• 1801-12: new managing committee
• 1801-12-20: associations Christmas ceremony

And here you can see the way, the dates should be sorted.
Year only should be interpreted (internally!) as: 1801-00-00
Year and month as: 1801-12-00

Maybe that's a (probably dirty) way of implementing this?
Fill "missing" date fields with "00", but don't show it in the ouput.

Subscribing - I need this too!

I need this too.

In addition to the issue of uncertain historical dates previously raised, I need to account for variable periodicity in certain types of nodes. For example, one of my clients has a series of papers whose publication schedule has varied over the decades; some are month-year like "December 1991" and others have a full date like "13 September 2001." There is currently no way to use the same date field to represent both as publication dates; the former gets recorded as "1 December 1995" which is not accurate, and which can lead to some confusion (e.g. a paper dated 1 April reporting on a conference that didn't even start till 4 April). And of course, many papers were in fact published on the first of the month, so we cannot assume any instance as being auto-inserted.

There is even more potential for variability in cases where granularity is set for hours or minutes. I set up each event at a conference as a node so that related video, lecturer bio, papers, transcripts, etc. can be attached easily. But the exact time of a presentation might not be known until just a few weeks before the conference. They are recorded as occurring at midnight in the meantime. We can mask this at the theme level, as no conference events occur after 9pm, but the same could be said of sites storing showtimes, tour itineraries, and any number of other things that occur throughout the 24-hr day.

Marked #342844: Partial dates as a duplicate of this issue.

Cross-referencing two possibly related feature requests:

• #104287: Time without a date feature
• #219794: Allow dates without years.

I need partial dates as well, and may be able to contribute to implementing it.

My project needs to store dates for old artifacts, mostly photos and documents. In many cases only the year, or month and year, are known. On the other extreme, we also have modern "artifacts" that have precise to-the-second dates.

From a coding perspective, it seems that we need another field that stores either (a) some indicator of precision (circa,century,decade,year,month,day,hour,minute,second) or (b) a second, partial representation of the date. For example, ISO 8601 allows for leaving off values that are not known. (c) a second date field that marks the other end of the range. I lean towards (a) or (b), as (c) could be implemented, if clumsily, with two date fields.

For my purposes, it seems that the interface should allow the user to enter as much information as they have, and derive the precision from this. So if someone enters only "1943", then this is stored as having year accuracy, "July 1943" has month accuracy, etc. (Not sure how would tell decade or century accuracy, however. E.g. '1900' or '2000' would be ambiguous.)

I looked into the module code a few weeks ago and the situation didn't look good: many separate functions that pass around only fully qualified dates. I'll take another look. I'd love to hear from anyone with more CCK coding experience as I've only done 'normal' modules before.

I've had some time to work on this and have a rough version working. Attached is a patch file for date 6.x-2.0-rc6 that demonstrates what is working so far. I'm no CCK coding expert so right now the goal is merely something that works. If anyone has time, I would love feedback on the direction this is going. This is only for evaluation, do not use on production sites.

The first issue is how to indicate that you want to accept fuzzy dates. For now, I've accomplished this by recognizing a special 'fuzzy flag' in custom date formatting: Set the 'Custom Input Format' and 'Custom Display Format' to 'F d, Y - H:i \X'. The '\X' at the end is the signal that fuzzy versions should be accepted.

So there are three levels of granularity accepted: Day, e.g. "March 14, 1945"; Month, e.g. "March, 1945"; and Year, e.g. "1945"

What do you think is the ideal way to do this? Should we add an option under Granularity that is "Fuzzy". However, there may be problems in 'fuzzy parsing' of arbitrary date input formats. If the input is simply "05/05", it will be tricky to get the system to recognize that those must be month and year. It would be even more difficult to recognize levels of granularity not expressed by the PHP date format, e.g. centuries, decades, seasons, quarters, weeks, etc...

The second big issue is how to store the granularity/precision within the database. For now, I'm using a clever hack: the precision is encoded within the seconds field. So the seconds field is ignored, and instead is used as an indicator of precision. I'm using this rather arbitrary mapping: 59=minute, 58=hour, 57=day, 56=week, 55=month, 54=season, 53=quarter, 52=year. So, for example, the date "March 1945" is actually stored in the database as "1945-03-01T00:00:55". When this date is displayed, the "55" at the end tells the display code to only show the year and month, so only "March 1945" is shown. The nice thing is that the data is still valid dates and can be re-used or exported without special treatment.

Another possibility, perhaps more elegant, would be to store a fuzzy date as a date-range. However, this would require more complex mucking with the field widget which is beyond my drupal skillz at the moment.

As an aside, my project has a lot of data in "seasonal" dates, e.g. "Summer 1945." I'm also working on getting the module to recognize these sorts of fuzzy dates. It seems that this would also be useful for business data where something may be dated in quarters, e.g. "Q3 2008".

Updating status.

Oops, wrong version.

Subscribed

What do you think is the ideal way to do this? Should we add an option under Granularity that is "Fuzzy". However, there may be problems in 'fuzzy parsing' of arbitrary date input formats. If the input is simply "05/05", it will be tricky to get the system to recognize that those must be month and year. It would be even more difficult to recognize levels of granularity not expressed by the PHP date format, e.g. centuries, decades, seasons, quarters, weeks, etc...

I was going to suggest making granularity as precise as what the user entered. E.g., if the user enters May 2005, then only make it as precise as that. Not sure there's a need for more granularity. However, you still need to save as a date code of some format, and I'm not sure there's a way to specify "no value" instead of, say, "00" in a field.

Well, it may be possible if you want to roll your own date comparison system (would be easy if this was object oriented--argh, Drupal!) with separate fields for each portion of the date, and each field can have a value or an accepted "no value" value.

The second big issue is how to store the granularity/precision within the database. For now, I'm using a clever hack: the precision is encoded within the seconds field. So the seconds field is ignored, and instead is used as an indicator of precision. I'm using this rather arbitrary mapping: 59=minute, 58=hour, 57=day, 56=week, 55=month, 54=season, 53=quarter, 52=year. So, for example, the date "March 1945" is actually stored in the database as "1945-03-01T00:00:55". When this date is displayed, the "55" at the end tells the display code to only show the year and month, so only "March 1945" is shown. The nice thing is that the data is still valid dates and can be re-used or exported without special treatment.

Sounds OK. If you get to the second, who would use fuzzy granularity? Only problem I see is that when sorting by date, fuzzy granularity items will probably be sorted at the beginning of the time period they describe. E.g., if I specify June 2009, it will probably be sorted as if it's 06-01-2009 00:00:00. So that seconds field stuffing could cause arbitrary sorting if we rely on PHP's date handling features.

Should there be a separate field to specify degree of granularity? Or use the "roll your own" date system mentioned above?

(removed my comment that probably was erroneous)

We will have to require that fuzzy dates be stored as ISO dates, the only type that will handle this properly. ISO dates have a built-in way of handling fuzziness -- you just use zeros for any unused date parts, so a date with only a year and a month will be 2009-01-00T00:00:00, and year only is 2009-00-00T00:00:00. This makes it very clear how precise the date is and the values will also sort correctly, plus when there is a standard for things like this, we use it. So I don't want to use a non-standard system of adding arbitrary numbers to indicate fuzziness.

The other issue is how to display the value. This will probably require a function that can interpret the 'accuracy' level of the stored date value and only display the right date parts. So if the format code is m/d/Y H:i and the date only has a month and a year, it would display m/Y. Code to do things like limit a date format to a requested granularity is already in the Date API, so we can already do that part.

Interpreting something like 05/05 is a very big problem indeed, one of the primary reasons why we can't do fuzzy dates now. We can't gloss over that issue, it must be solved in whatever solution we come up with. There is no way we can come up with a system that could accurately guess what that should mean in any situation in any country (depending on the country and situation it could mean YY/MM or MM/DD or DD/MM or MM/YY). So there is no way we can just accept anything the user inputs and assume we know what we have.

I think we will have to tell the user what the expected format is, and then accept blank values for part of the date, in that format. That way we can be sure what 05/05 means. So I would have a date that says the format is 'MM/DD/YYYY HH:MM' but will accept something like 05/00/2008 for a month and year in a text field, or with a select list a blank value for the everything but the month and year. Then the field definition would have to have a flag to indicate that fuzziness is allowed so it doesn't set a validation error or blank out the results because it isn't a valid date. You can't use the Date Popup calendar for fuzzy dates because the javascript code will choke on anything other than a valid date, and we won't allow repeating dates for fuzzy dates because the RRULE code and date repeat logic expects valid dates and won't work right without them. And I don't think we'll allow timezones for fuzzy dates because applying timezone conversions to fuzzy dates wouldn't make any sense and would probably bomb in all kinds of ways.

So this could be a new kind of date field rather than trying to mix this into the way existing fields work. It would be an ISO date with just two possible widgets -- textfield and select -- and no timezone conversion. Since it's a different field, it could (and maybe should) be created as a separate field module rather than trying to shoehorn this into the existing date fields. That would simplify the logic quite a bit.

ISO Dates are certainly the way to go--the only date standard that can encode precision. One minor point: from wikipedia and w3c, it seems that partial dates are represented in ISO 8601 by leaving out the unknown parts, not by filling with zeros. (Presumably because zeros would be ambiguous in the time field, e.g. in the ISO date "1997-07-16T19:00:00", one couldn't be sure if minutes and seconds were unknown or actual zeros.) So a date with only a year and a month will be merely "2009-01".

I'm a newcomer to the Date Module codebase, but it was clear that a date was converted/processed multiple times in the normal flows of saving or displaying. I believe that every date gets converted to a PHP Date object at some point, and AFAIK, these objects have no inherent way to represent fuzzy dates. My point is that it would be a significant re-write of this module to support fuzzy dates without a hack like my patch uses. It seems this require modifying the flow to keep the date represented as an ISO string throughout all processing, or creating a "sidecar" data object alongise the php object to record date precision.

Karen, you certainly know the code better than I. If you want to undertake such a re-working, or if you see a better way of doing it, I'm happy to help out in either case.

_{(As an aside, my project is also a tool for Elders; cool to find ElderWeb.)}

Leaving out the values is an option if we make this into a different field type, it is not an option in the current fields. I have read in other places that it is also valid to fill zeros in for the unknown values. Either way, we can tell how precise the value is, so either will work.

The current code does lots of date validation, but it *does* accept ISO dates with missing values (you can do year-only or year-and-month-only dates now and they work). So long as we have at least a year in an ISO date, and the missing parts are padded with zeros, the date will work in the current code. I don't think anyone is suggesting that the fuzzy date would not have at least a year (i.e. it looks like the 'missing' parts will be the less precise parts of the date), so this is at least theoretically possible.

However, as I noted above, we may really want to create a new date field that doesn't use all the date validation and timezone conversion done in the current code. It might be the easiest way to do this and the code would probably be easier to follow.

I need to mull this over a bit...

Interpreting something like 05/05 is a very big problem indeed, one of the primary reasons why we can't do fuzzy dates now. We can't gloss over that issue, it must be solved in whatever solution we come up with. There is no way we can come up with a system that could accurately guess what that should mean in any situation in any country (depending on the country and situation it could mean YY/MM or MM/DD or DD/MM or MM/YY). So there is no way we can just accept anything the user inputs and assume we know what we have.

For the sake of intuitiveness, should fuzzy date/times have separated fields for each time unit in order of increasing granularity? Year first, seconds last. That way there's no guessing or working through the American date representation convention where order of display does not correspond to order of granularity. Also no need to use 00. Just leave undefined granularity blank.

A good approach for parsing fuzzy dates may be to use successive calls to the date_limit_format() function in date_api.module. This function is passed a granularity and a php date format string, and returns a new format string limited to that granularity. The date field would have a specified format (as now) but allow the user to enter a fuzzy string; this string would be parsed by successive calls to date_limit_format(), moving from more precise to less precise until it finds a format which fits the user's string.

For example, if the format for the date field is "F d, Y - H:i" and the user enters "July, 1942", the system will try increasingly fuzzy formats:
"F d, Y - H:i"
"F d, Y - H"
"F d, Y"
"F, Y"
...At this point it will get a match, and record that the date has only 'month' granularity. This would be converted to an ISO date of "1942-07" (or "1942-07-00T00:00:00" if we use the zero format.)

This approach solves KarenS's "05/05" problem in an at least predictable way. If the format is "n/j/y" (American date format) and the user enters "03/05", it will be parsed as March 2005 (and not May 2003). It is then up to the site administrator to provide explanation to users as to what format is being used for parsing.

Hi,

Has any more progress been made on this? It seems that if the current version of Date allowed for the entry of a zero value for day and/or month, it would address most people's needs. Internally a sort would detect the granularity from the presence of these zeros.

But of course I'm not a programmer. Obviously this is an easier said than done case.

Hi wanderingStan. I'd love to give you some feedback on your patch. But I've never installed a patch before. So I have a couple questions.

I am on a Mac and attempting to do this via terminal. I THINK the file I want to patch is the date.module inside date, which is in the date top directory. This is where I put date_fuzzy.patch

So in terminal (on the Mac) I change to the directory:
JW-Pwrbook:~/Desktop/date jw$ cd /Users/jw/Desktop/date/date
Then I type:
patch < date_fuzzy.patch

I get a bunch of errors.

So then I said, "Lets install it into the base date folder. I did the same procedure to a fresh download of date 6.x-2.0-rc6 and placed date_fuzzy.patch in there. This time I get:

can't find file to patch at input line 4
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|diff -urp d:\Temp\date/date/date.module .\date/date/date.module
|--- d:\Temp\date/date/date.module 2008-12-02 10:32:35.000000000 -0700
|+++ .\date/date/date.module 2008-12-18 17:14:40.359375000 -0700
--------------------------
File to patch:

Am I patching wrong? Does date_fuzzy.patch need to be renamed? I'd love to test this and help if I can, but I haven't got past square one.

well I got patching sorted out. I needed to put date.module and patch inside the same directory and run the patch.

I went through the process. replaced the module with the patched one and could not get year or month/year to work with my day.month.year granularity.

Is there anymore development going on in this regard?

Interesting issue.

One problem with the ISO format is that it can't handle the kind of phrases that often come up in conversation, like "in the 1980s", "in the 1800s", "in the first half of the 20th century", "one cold winter around the turn of the century".

Regexes, however, can. The above all become something like:
198./.*/.*
18../.*/.*
19[0-4]./.*/.*
(199.|200.)/(11|12|1|2)/.*

Just a thought. Can't see anything such vagueness would be useful for, really, other than stuff like timelines. And for most cases, simple date ranges do them just fine already.

subscribe

Dewi: From my reading of the ISO spec, some of the phrases you mention *can* be represented. The crux is this detail

For reduced accuracy, any number of values may be dropped from any of the date and time representations, but in the order from the least to the most significant.

So, for example, "in the 1980's" would be "198", and "in the 1800s" would be "18".

But this still doesn't help all issues. I have a lot of date data expressed in strings like "Spring 1947", and I know others have dates in terms like "2007 Q4".

I agree that we should stick to the ISO spec as far as it will go, but I would like the potential for other more esoteric date representations.

subscribe - #12 gives a good idea of my requirements

This would be perfect for what I want to do - I am constantly getting more information on dates of events that can start off as just a year and end up with an exact date. Same as #12

Wow, this request has been going on for almost a year now. Is there any progress on this?

Will this likely be implemented for Drupal 6 in the next time?
If not, are there any suggestions, how you might get this (or similar) on a different way?

subscribing

Subscribing

Subscribing

subscribing

This is not really a working patch, nor has anything been reviewed, so it is not ready to be included in the code.

subscribing

2KarenS: In your opinion can it be realized by custom module instead?

I see it as 'fuzzy date' widget that stores 'from' and 'to' dates of selected period and then displays it in suitable manner. Am I on the the right track?

What no2e said is already how DATE and DATETIME column values are handled in MySQL (allowing zeroes in any particular date sub-field to act as a wildcard: e.g., '2009-12-00' means December 2009 as the entire month, without specifying a specific day).

If Drupal were MySQL-only, this would therefore not be too difficult. But since it supports multiple databases (PostgreSQL in 6.x, any PDO-compatible database in the upcoming Drupal 7, if I understand correctly), we cannot rely on this.

Can we not say that this feature requires MySql until it can be developed further?

@#49: That would be fantastic.

subscribe

I also need this to work for birthdates and deathdates that are not always known exactly.

+1 for mysql only

Would it even be acceptable to have a Module be database-specific? Is it not a requirement that all Drupal modules use the Drupal database libraries (if they do database access at all), which currently allow either MySQL or PostgreSQL, and may or may not allow database-specific features?

As I understand it, Drupal 7 will use PDO, which will allow many more databases, including Microsoft SQL Server. I know for a fact that MS SQL Server, at least as of 2005 (2008 may have changed this), does not allow zeroes in date parts (it does in time parts, of course, but only as actual zero values).

Subscribed.

Subscribing. Need the functionality described in #12.

I have books and articles in something of a library. Books have years, whereas articles have years, months and days.

Any progress on this?

Thanks

subscribing

This would be very handy indeed. I have a content type for music releases (albums, DVDs, EPs, ...) which should also be able to contain upcoming releases. More often than not, only a month and/or a year is known in that case. I am tempted to investigate the applicability of wanderingstan's patch, despite his express warning not to use it in production, because having to fill in a bogus date is hardly user friendly.

Subscribing!

Subscribing

Subscribing.

I have a custom node type for records that date back to the early 1900's; except some of the records are incomplete and only have their given year. Anything other than the full date DD/MM/YY throws an error on submit.

Subscribing. This would be great in conjunction with the timeline module.

Looks like it may be a while before a solution is found. Meanwhile, has anyone come up with a good workaround with this or any other modules?

How is this a support request?

Subscribing

Subscribe.
Going to store values in the database with 00 in a bulk operation, if that value is null. Going to look into displaying it so it cuts off the day or day/month. Do you foresee any issues by doing this (00 for null) with views integration? I'm side stepping the validation issue here.

Right now this stored in the database
1866-12-00T00:00:00
Outputs this
Saturday, December 1, 1866

Would like it to output
December, 1866

Subscribing - Same problem as everyone else. #12 describes it nicely. Will try the patch in #19

subscribed

I'm working on a genealogy-related project with the same issue: Need to be able to enter birth/death dates with varying granularity -- sometimes just the year, sometimes year/month/day -- and would like to use the Date field.

There must be lots of project involving historical events, people, etc. that need this...

Has anyone tested/implemented a solid solution (the patch above, or something else), or is there some other approach people are taking? Thanks!

subscribed

subscribing - need this like ham on a steering wheel - no, wait, like bread and water

oh - please Date module developers - breathe thy sunlight towards this scurvy ridden scratchy, itchy rash

I've started something along these lines. So far it isn't too ugly, but the date module and its subsidiaries do a lot of reconverting between formats, making this issue much harder to implement and leaving a lot of places where a blank entry gets silently converted to a 0, losing the NULL versus midnight distinction. I'll post back once it seems to work for some use cases. It is very unfortunate that the DateTime object built into PHP doesn't appear to have any support for this distinction, and that this is the usual working storage method employed by date.

Incidentally, the reason I've thrown myself into this fray is because the current "All Day" label is a simple attempt at such granularity that is very badly mangled by things like time zone conversion, so it doesn't work well for us. I am only bothering to deal with the ISO/"Date" field; the Datetime and similar don't seem to have any way to store the Null versus midnight info in the DB, therefore the only workable method I can figure out for them would be along the lines of the second-field hack of previous posts, or an additional DB column.

I have patched my date module to do the "simple" case mentioned in this thread (holes at the end of the ISO date). It has been in production on a site for over a year now, currently it runs on Drupal 6.14 with date 6.x-2.4.

What I have:
- a "dateflex" type, looking like a datestamp, which stores dates as ISO plus a precision ("2009-12-15T11:00:00|4": the "|4" tells that this date is precise to the hour). Sort still works beautifully.
- start and end date differenciation for year, month and day; so that year 2009, for example, is 2009-01-01T00:00:00|1 when a start date, but 2009-12-31T23:59:59|1 when an end date. Thus a query looking for "what is happening right now" (start date <= now AND end date >= now) will rightfully return events marked "from 2007 to 2009".
- fuzzy input (for now, in French: "xx" -> day xx of current month; "xx yy h" -> day xx, at the yyth hour; "xx/zz" -> day xx of month yy of this year; "tttt" -> year tttt. And so on, detecting from year to second precision).
- output formatting is for now a work let to the theme. My theme has code to assemble pretty dates, that take into account both start and end date (so that "from december 31st, 16:00:00 to december 31st, 20:00:00" displays as "le 31 de 16 h à 20 h" (which could translate to "on 31st, from 4 pm to 8 pm")). But, 1., code is a bit ugly, and, 2., it doesn't do date-crossing (for New Year's Eve, you would get a full "du 31/12/2009 à 20 h au 01/01/2010 à 6 h"; working on the code a bit more could certainly add intelligence to it, to understand that no other 6th hour will come before and so this can be compressed to "le 31 de 20 h à 6 h").
- (and by the way I've hacked Views to make it return for which date it has selected a node when this node has multiple dates, but that's another story)

I'll try to separate all those points to create multiple patches, so one can test them one by one (and I thank January-1sts-week-ends for the time it'll give me!).

But:
- as you said, Karen, no timezone of course. Conversions in the PHP code are now surrounded by "if ($field['type'] != DATE_FLEX)"s everywhere.
- no centuries. For archeology sites, perhaps an additional precision level could be added (as of now, 1: year, 2: month, …, 6: seconds).
- input is heavily dependent on locale. For my own usage, I have hardcoded French-style dates, but it should be made modular. Parsing is done in PHP, in a very empirical way, so I'd say one php by language (I had a cleaner JS implementation that had a pseudo-grammar, but… I had to make the PHP version a bit quickier).
- as said, output has not been integrated to the Date module.
- … and input uses some old code of mine, with everything in French (comments, variables, functions, and so on).

Hum, while creating the patch(es), I see that I have another "by the way" (or "one more thing", as would one say): I added a notion of weight of date. As I use dates in a agenda, I had to make a view "what to come, in five dates"… but of course I didn't want the five next local weekly meetings to come, and hide the national meeting in two months! So, I add a weight to each event (well, to each date of each event, as dates are multivalued), and my "weighted date" is weight / min(1 day, date - now): while the weekly meeting isn't tomorrow, it stays behind the national one.

And of course theres a "re-sort" applied after that, because, although if I need the weighted date to filter which five events come out, after that I want the five results to be sorted by date, not by weighted date.

But that whole will be another patch.

So, here we go… First patch, no rework (read: French-style date input), handles input and storage (and I have a bit of output too but it seems it is not used in the admin view).

Made for Drupal 6.14 - Date 6.x-2.4, and just retested on a clean install (Drupal 6.x-dev-2009-12-17, CCK 6.x-2.x-dev-2009-12-24, Date 6.x-2.x-dev-2009-11-11, Views 6.x-2.x-dev-2009-12-25, MySQL).

The test was:
- Install Drupal and modules, activate Locale, Content, Date, Date API, Date locale, Timezone , Views, Views UI, update.php
- Create a content type, let's say Event, add it a new field of type Dateflex, with an optional To date (multiple values work too, not tested here but I use it daily on a production site; other settings will be mostly ignored with dateflex).
- Create 4 Events: New Year's Eve (From date: 31/12/2009 20h, To date: 1 4h (remember we input French dates? OK, so the month is correctly placed)), 2009 (From date: 2009), 2010 (From date: 2010), Long long week-end (From date: 31/12/2009 16h, To date: 3/1; and, yes, the boss said we should all be out at 4 p.m. yesterday)
- Create a view, for example what_now, for nodes, add it two filters for Date, with granularity: second, and AND filtering. First filter on From date <= Date default(now), the second one on To date >= Date default(now) (do *not* use From date default(now))
- Add field Node: title to the view, so the preview will return something; you'll get 2010 and Long long week-end (if I had chosen a "day" granularity, in addition I would have got New Year's Eve, because then the view would have been a "what_today").

Patch is in two parts (to apply from your Drupal's root directory, the one containing "modules" and "sites" and so on):
patch -p0 < /tmp/dateflex.patch # Modifications to the Date module.
tar xzf /tmp/dateflex.tgz # Those are the two horrible, wholy French-commented-and-variabled, files.

Now… If anyone feels this extension is interesting, I would say next step would be to define English date input rules (and do this would require the modularization of date parsing).

Or, to be more ambitious, make the input part of dateflex a full input widget (after all, this is what I initially conceived it for), so that it can be plugged to any date type. But presently I wouldn't know how to do this, because I don't know if (and, if yes, how) date input can hold the date's precision before it is dispatched to the chosen date type.

(or I could first explain the "two horrible wfcav files" in English)

Tell me (… uh, not everybody at the same time!) if this is the right direction to answer your needs.

Hmph, resubmiting the patch: require_once were erroneous.

The .tgz of #75 is right.

For proof-of-concept, I have quickly integrated my date theming into Date (instead of letting it in my theme, as said in #73).

But:
- this is in French (this shouldn't be too difficult to translate… but this shows a need for modularization)
- this is a copy-paste of my code (so, unlike the previous patch, it doesn't follow Drupal conventions, like spaces-for-tabs, parenthesis spacing, curly braces)
- and it is a brutal "if dateflex return …" formatting, letting dateflex dates no other formatting option than this.
- that's why I call it a proof of concept

Attached is the current version of my patch adding flexible granularity. It appears to work alright in testing I've done so far. What I do is change all DATE_ISO fields to allow flexible granularity by default, with no configuration to that end. This is then in contrast to the datetime or timestamp date storage methods. Then, the user will be able to enter whatever they want for a DATE_ISO type field, up to the allowed granularity settings for the field. So, if a field has granularity up to second, they can just enter YYYY-MM-DD and have valid input. The importance is that this is carried throughout.

On the input layer, in the text and popup widgets and on the back-end processing, I have added support to remember this blank vs 0 distinction. So, something lacking an hour will get passed through to the storage, will not have its timezone converted because it is marked as lacking time granularity, and will be stored as "YYYY-MM-DD" in the database varchar field (a valid ISO format date as previously discussed). This is in contrast to the previous method of reverting everything back to "YYYY-MM-DDTHH:MM:SS" long before it was stored, and also timezone converting, rendering the All Day tag somewhat meaningless.

Then, upon retrieval, the granularity will also be determined when loading ISO dates, and it will not be timezone converted if it lacks time granularity. It will also be displayed without the trailing 0s and such if it is a DATE_ISO marked as lacking that granularity. Finally, the all-day demarcation for DATE_ISO uses this information rather than the 00:00:00 assumption under which it previously operated. I didn't do extensive testing with views displays and other fancy stuff on this end.

I also added some validation, namely that you need the same granularity on from and to fields (otherwise the timezone conversion would go all haywire, with only one changing).

I have tested this to a moderate degree with all the timezone types and the two widgets I made it work for, text and popup. Adding additional widgets wouldn't be too hard or time consuming. The functionality for non-DATE_ISO fields appears to remain identical to before--IE you always have to enter all the required granularity for the field.

One known issue is that the validation for the popup widget allows you to enter a time for the FROM date and no time for the TO date, and then it automagically makes the TO date time match the FROM date time. I haven't looked into this, but I don't think it would be hard to diagnose.

If people like the direction of this patch, we should probably add a setting that allows or disallows flexible granularity on a per-field basis. This would be very easy to do, just adding that setting to the cck field and adding a couple of lines in the validation layer that would only allow the new flexible validation to pass if the setting was checked. Alternatively, we could make a new field type instead (although both would be storing data under valid ISO date spec)

The main way this patch works is by adding a granularity property to DATETIME objects that mimics the format used for settings--ie it is an array of ('year', 'month', 'day') or something. This is filled when the original input is parsed, so that it can tell if blanks or 0s were there and act accordingly. This is then passed around, converted to ISO dates and Date arrays, and eventually converted to an ISO date and stored in the DB. A similar thing happens on load.

I can't seem to get the patch in #79 to run properly. Is this a patch against 6.x-2.x-dev ?
Sorry -- probably something I'm doing wrong.

Yeah, it's in the DRUPAL-6--2 branch of date.

Okay, thanks. I ran the patch against the current dev version, and it seemed to run, but there is no difference in functionality -- but maybe I don't understand how it's supposed to work. I still get "Date of Birth is invalid" if I try to enter, say, 1918 instead of 1918-11-11. Are there other parameters I need to work with, or something I need to set up somewhere else?

I'm using:

* date field
* text field with custom input format
* Input format: 2010-01-07 15:01:01
* Granularity: Year, Month, Day
* Default display: Medium
* No time zone handling

Wow! What a patch! I know this is something a lot of people want. In fact, it is something I could use myself. I don't have time to dig into this immediately, but it looks like an interesting approach, so further testing by anyone else who's interested would be helpful to move this along.

In particular, I am concerned about testing various timezone settings and dates with various granularities to be sure timezone adjustments don't get introduced when they shouldn't.

I will try to get to this when I can, but any other input would really be helpful.

sub

@toddwoof
This patch works only with second, minute and hour now:

TODO not hard to support fuzzy granularity further, ie years and month only, mainly depends on input elements.

subscribing too :)

Ah. Okay, thanks! For my purposes -- genealogical/historical dates -- I need year only, year-month and year-month-day as granularity options.

How hard is "not hard?" This would be super useful. Thanks!

Actually the genealogy/historical stuff is my use case too, so I'm more than happy to allow for that :)

Note: for archeology and ancient history, whichever patch is taken as a base (David's one or mine) won't allow negative dates (and bigger than year 9999 ones, for astronomy lovers) without loosing sorting.

This would require a completely different storage to store (and sort, and filter) dates having:
- a negative year (e.g.: year -0052 to be sorted before 2010… and before -0001 too)
- or more than 4 digits in their year (those old Neanderthals! I forgot, when was the last time we met?)
Could we use awfully encoded floats, like 2010.0109005516 (and expect the database to preserve our precision, which encodes time to seconds)

Moreover, genealogy can make dates a bit harder: a single date (let's says birth date) could be a range (born between 1472 and 1473), a multivalued date (born 1472 or 1476)… or anything else (born before 1473).

OK, that was just to make obvious the cases no one should be dreaming of. So that we can continue speaking of what will be possible… and implemented.

I think #88 means the patches need work?

I would say there are some things we won't attempt, negative dates, etc. This patch should not try to attempt those things. If there's a need for those other things, they need a completely new kind of date field that uses different logic, we don't need or want to stretch a regular date field in that many directions.

The patch needs work primarily to add the functionality to make the month and day optional. I don't think we can make year optional, not going to attempt that.

(I'm a bit verbose sometimes… So, Aren, yes, what Karen says in #90 is what I meant in #88)

I spent some time trying to make this work with day and month granularity being 'fuzzy' and was not able to get it working. It looks like that is supposed to be 'easy' but I can't get it working. @David Goode can you update your patch with what you think it will take to make that work?

Also note that some of the things you have commented out with questions about why it is necessary is for things that were needed to keep year-only and year-and-month-only dates working correctly, in particular with the select widget, so you'll need to test that these changes don't break something like a datestamp using a select widget that has the granularity of year and month only.

Please make this work.

Hey Karen et all! I'm now working on extending the granularity to month and day, and I should post a patch shortly. Another outstanding issue I'd appreciate input on is the one addressed by guillaume.outters, namely sorting with flexible granularity. How should something like a query based on a range of months deal with something that is stored only with year granularity? Currently it just wouldn't find it (I assume)...2008 is less than both 2008-03 and 2008-04. I actually haven't looked at this sorting/views handler/filter logic, so if anyone else could check it out/test it/patch it it would be very helpful. Additionally, we should probably make the flexibility optional on a per-field-setting basis, and if I have time I'll try to add that to my next patch.

On sorting/queries: Good question. From the standpoint of genealogy/history dates, I'd suggest:

* For sorts, put items lacking some level of granularity on top. So 1918 comes before January 1918; and January 1918 comes before January 1, 1918.

* For filters, any one of these would work for my case:

A. Don't return items with less granularity than the requested filter. So, "between January and March, 1918" would not return any results that lack a month.

B. Show results with less granularity if the entire encompassing range is included. So "between January and December 1918 would return all records with 1918, whether or not it has a month. (Only useful because someone might accidentally do that...)

C. Have an option for including items of lesser granularity. So, between x and y, 1918" would include all records with 1918, whether or not a month is specified, if the option is checked.

Very excited to see this coming together -- thanks!

Hey all, just finished current patch. Now allows granularity down to year-only. I also cleaned up some other stuff and added a flag on a per-field basis that allows flexibility--if not present, date fields should behave exactly as before, requiring whatever granularity input format they are set to receive.

I made it a per-field rather than per-widget setting because it has storage and display ramifications, although it is also closely related to the input-format per-widget settings. It also only works for 'date' fields, which the widget settings form doesn't seem to know about. Possibly could be moved to per-widget? Thoughts?

The flexible granularity option and functionality are both now only enabled for the 'date' fields, not datetime or datestamp.

The major todos remain:

1. figuring out if the sorting/filtering capability is sufficient
2. dealing with the
   

   +      // Breaks dynamic granularity patch and seems unnecessary
   +      //if ($from_type == DATE_ISO) {
   +      //  $date_array = array_merge($date_array, date_iso_array($date));
   +      //}
   

   part on line ~1250 of date_api.module. Karen made a good point that this is there for a reason and its absence could probably break stuff. To me it looked like the relevant parts would be filled in regardless, but I perhaps didn't cover this case in testing, and I'm not familiar with the motivation behind this code segment--an alternative and more thorough testing would be helpful.

3. Dealing with repeat dates, which I allow to have flexible granularity but which almost certainly would break. We should probably just not allow such widgets to have flexible granularity unless a good solution can be found--ie it doesn't make sense for year,month granularity dates to repeat every day... Not allowing them to have it is simple though, just change the #date_flexible flag that's passed around to be false in the case of repeating widgets.
4. More testing!!! Date module has 3 different types of fields times like 6 different widgets, and that's just what's included by default! If you also want to see this functionality land, then help by installing the patch and testing it!
5. I found a few unexpected misbehaviors in the DATE_REGEX_LOOSE and DATE_REGEX_ISO strings. I changed the latter to suit my use case because it doesn't appear to be used anywhere in date module--tell me if this is a problem. Basically, DATE_REGEX_LOOSE has the problem (known? not?) that if you give it something like 2008-03 (meant to be year-month) it will match it to year: 2008, month: 0, day: 3. Maybe this is known/we should open another issue about it. Fixing not too hard, just involves a bit more obfuscated regex.

Just tried it. On my site it now works to year-month, but not to year.

So, I can enter 1918-01 and it will save and display January, 1918.
If I try to enter 1918, it returns "[date field] is invalid."

What field settings have you used that DO work, so I can test the same arrangement?

I'll also re-apply the patch and try again. Maybe it didn't work fully, or something. Anything else I should check?

Hey, no thanks, that was a very good catch. The attached patch does a lot more cleaning up and fixing and makes granularity actually work down to year only. This is a case in point for why testing is very helpful :-) If you want to help test, things I'd really like looked at are:

1. datestamp versus date fields, see if behavior makes sense, the former doesn't break.
2. Different input formats, see if they all work as expected
3. Different max granularity settings for variable granularity fields.
4. Varied places where dates are output, check that limited granularity is preserved (IE a date without a day doesn't display with 00)

The new patch works as expected -- thanks!

So, I can at least say it works with:

* Date field, set as "text field with custom input format"
* Granularity set to year/month/day (so, no timezone handling)
* Node view.

I'll tinker with views and different formats.

Thanks for working on this!

Maybe this is obvious -- but with fuzzy granularity set, it appears that an exposed filter using a date field doesn't work as expected.

Example 1: Exposed "birth-date" date field filter, set to "select" with the operators exposed:

* If I enter just a year in the exposed filter -- say, "birth-date is less than year:1850 (and I skip month and day) -- it returns incorrect results (all records, I think).

* If I enter a complete date -- say, birth-date is less than year: 1850 month: 01 day: 1 -- it returns better results, but it includes records with the date set as 1850 (with no month/year), which should be excluded.

The main problem seems to be that I'm able to enter only a year when using the select widget, which breaks the filter completely. So, I tried:

Example 2: Same exposed field, but set to text instead of select -- which forces me to enter a complete date in format yyyy-mm-dd.

* Much better from the user perspective, since I can't enter only a year and get completely wrong results, but the same problem: If I enter "is less than 1850-01-01" it will return a record with 1850 and no month/year.

Doesn't seem to work for me.
Drupal 6.15
Date 6.x-2.4

I have:

• patched the module with the last patch 2593...patch (although I had some difficulty)
• enabled the Date, Date API and Date Timezone modules (tried with and without the Date Locale module)
• created a custom node type and added a field of the type Date (I understand this is the one using the DATE_ISO format) with minute granularity and the flexible flag checked, blank default
• disabled timezone both on the field and on the site globally (tried with timezones enabled too)

Now if I enter a date without the time value, the field gets a T00:00 value and the date is displayed accordingly.
If I edit the value in the database and remove the time part, the date is displayed with the (All day) string attached.
If I now edit the node and save (without modification) the T00:00 returns.

Upon entering a date with year-month only, I get an error (warning: array_pop() [function.array-pop]: The argument should be an array in /var/www/polinst.hu/sites/all/modules/date/date_api.module on line 1436. [repeated with line 1438, 1441, 1444 and then all four messages once more])

What am I doing wrong?

Did I patch incorrectly? (never done it before)
Placing the .patch file in the date module folder and running "patch -i <patch filename>" I had to specify the filenames of files in subfolders, even though the filenames I specified were the same patch was trying. I received no error messages during patching. The files have different sizes (at least the ones I checked).

Could someone who managed to make it work please point out the necessary steps and settings?

subscribing

subscribing

Subscribing

update on the patch:
It gives an error when patching Date 6.x-2.3, it patched fine with no errors on Date 6.x-2.4.

It does not work with the select widget or pop calendar so far just with the text field with custom input. When a date like Feb 2010 is added with the Select and Popup Calendar widgets when re-editing the node it adds the day as 1st of the month.

Another update:
The 259308_98_dategranfixes.patch only works with the date format : Month Day Year (Feb 10 2010) other dates formats when you re-edit the node and save the date field as: Feb 2010 the DAY value is added (Feb 1 2010) :(

Year Month Day also works. I can enter 1900-01, for January 1900, and it will display 1900-01 (not, say, 1900-01-01) even if I later edit and re-save.

I have read this thread with great interest, as I have been using a fuzzy date format of my own design in a database for several years. Based on ISO 8601, it evolved as I wrestled with various fuzziness issues one at a time.

Eventually I decided to revise and rationalise the format, and produced a White Paper about it in the Summer of 2009 to systematically lay out my thinking, prior to redeveloping my database as a web application.

At that time I hadn't heard of Drupal, and the original version of the paper was not released anyway. More recently though I started reskilling on Drupal and discovered this forum, where all of the problems that I've been working on are being explored.

This prompted me to revise the paper (version 1.1, February 2010) and add more material to cover a few fuzzy date situations, as discussed, that hadn't occurred to me.

This attached White Paper then: "Fuzzy dates in military history databases - FZY-D, a proposed variation on the ISO 8601:2004(E) datetime format", may be useful to all those contributors looking for a way forward in handling fuzzy dates.

Applied patch against 6.x-2.4

As per #105 this isn't working with the select list widget. After submitting a date with just a year (eg, as 2009) and leaving drop-downs for month and day empty, the value being stored in the database is 2009-01-01 not 2009.

subscribe

To make this work with the select list widget, I've added the field as a textfield, and then I'm using jQuery to replace this with select lists. The user sees the select list input (assuming they have javascript turned on) but Drupal still gets the input expected from the textfield, hence working fuzzy granularity.

That's a pretty hacky solution, the module should recognize empty select fields as to be fuzzy?

Yes, I spent quite a while debugging trying to work out why the module wasn't recognising empty select fields. I ran out of time, and had to come up with something!

I added some trace output but couldn't work out which stage in saving the field the fuzziness was being lost.

Hey, all, sorry for the hiatus. I hadn't added select field support to the previous one--it only worked for text and popups, as I said in a post. However, I've now added that, so it works for all the built-in widgets i think. I also did a bit of further clean up and made it so that repeating dates don't have the flexible option. If this is important to people it seems possible to do but it might take a while, things could go wrong, and the repetition interface would probably have to be ajaxed up for it to be intuitive (IE the day options only show up once you enter day/time granularity in the field)...

Thanks to everyone who is testing out the patch, especially toddwolf. I am not sure why the select filter was going haywire previously because it *shouldn't* have been affected by the patch until now. Was it working properly before? Either way, try it out with the new patch. However, I honestly haven't looked through the views filter stack for date at all, so it very well may be messed up. Here's the way forward on that front as I see it:

1) The date filters on views should allow fuzzy granularity up to the mysql query stages, where it will get lost at this point. This may work already as the inputs are shared with node forms, but I haven't tested it at all.
2) The granularity should now be lost reasonably, IE just by replacing everything with 0s. This should happen now unless something is going seriously wrong. This is probably the stopping point for the current patch, although some things won't behave properly under this paradigm (IE queries for month ranges not returning full-year dates)
3) In the future, we should implement a custom filter that deals with the granularity intelligently. IE, for a range of years it should go from 1st second of start year to last second of end year, for ranges of months it should add an "OR char_length(isodate) = 4 AND isodate = year_of_query" so that year-only dates are included, etc. This hasn't been done at all and would be a great place for someone to help out!

David

Thanks David,

This works for me now with select lists.

The only facet being that no data is saved in the field if a custom input format is specified on the field settings.

subscribing

Subscribing

subscribing

Subscribing... keep up the good work!

+1 to patch #114. Still a few issues for required date fields, but much closer... certainly usable with caveats below and will go into production for a project I am working on.

Tested
Date 6.x-2.4
Drupal 6.16
PHP 5.29
Field granularity Y/M/D (no time zone conversion)
No To Date

Select widget type (field not required)

• widget input format must be M/D/Y (Y-M-D, Y/M/D do not work)
• fuzzy granularity input Y works
• fuzzy granularity input M/Y works
• fuzzy granularity input M/D/Y works
• fuzzy granularity input D/Y defaults to Y
• any other fuzzy granularity input combination is not stored (M/D, M, D)
• views sorting works
• date formatting works (tested M j Y, j M Y)

Select widget type (field required)

• fuzzy granularity input does not work (Y defaults to Jan 1 Y, M/Y defaults to M 1 Y)

Text field with custom input format widget type (field required)

• widget input format must be Y/M/D or Y-M-D (M/D/Y do not work)
• fuzzy granularity input Y works
• fuzzy granularity input Y/M works
• fuzzy granularity input Y/M/D works
• any other fuzzy granularity input combination results in validation error
• views sorting works
• date formatting works (tested M j Y, j M Y)

subscribing

subscribing

subscribing

I've tried patch in #114 with instructions in #120 with not much success, date field without all 3 components (m,d,y) is just not showing up

I have tested #114 successfully under the following conditions:

Date 6.x-2.4
Drupal 6.16 (Pressflow 6.16.77, actually)
PHP 5.2.8

Field type: Date
Widget type: Text Field with custom input format
Input format (date()-style): Y-m-d
Granularity: Year-Month-Day

Users may omit the smaller components. Flexible granularity is only allowed by omission (using value '00' for a component is considered invalid with the patch, which is fine with me).
Omitted components are represented as '00' in the ISO-style date strings that get stored in the database.

Hey everyone! Thanks for your input into this issue thus far. I bring both good and bad news. I was approved to do a Google Summer of Code Drupal project on rewriting major aspects of the date API, and I intend to add support for flexible granularity (including intuitive sorting and views-based querying) as well as (hopefully) BC dates and other cool stuff while streamlining the code. That's the good news; the bad news is that this is only intended for the upcoming Drupal 7 release.

However, the backporting job would actually not be too difficult (I don't think) for someone who is willing to drop PHP<5.2 support and is fairly familiar with (especially) the D6 CCK and D7 fields APIs and their differences. In most areas the D6-D7 and old-new API changes are largely distinct, so someone well-versed in CVS diffing and patching might not have too much trouble, although it would still certainly take some time. Anyway, if someone wants to volunteer during July or so (once the new API work has progressed) to do this I'm sure others would appreciate it.

I'll keep this issue posted with any updates, such as CVS locations of the new code, but I don't think I'll personally be doing much serious work updating this particular patch given that a whole new API change is probably coming along that will incorporate these changes much more elegantly.

subscribing

subscribing

subscribing

subscribing

Hey all, the work for SoC was only for D7 date. Should have posted this earlier, but I was tracking it on github here: http://github.com/davidgoode/date. Hopefully a lot of it will get into the releases for D7 date module.

subscribing

@David Goode:
Just curious, any update on your progress?

subscribe

subscribing

subscribing

we need this !

New features go in latest version. Been way too long since last patch, so reverting to active.

Subscribe

just as feedback - are using the patch above which ist working fine.

Would be great to have it in the stable version, anyway.

I too need the ability to submit partial dates.
I've applied the patch supplied by #114 to Date 6.x-2.dev and followed the steps from #120, but I can't make it work.
If I use custom format M/D/Y with the "Select" widget the date field is missing altogether. If I select one of the existing formats (e.g. 01 Feb 2011) I can add a date like Feb 2011, but this date is later displayed as 01 Feb 2011. If I omit the month then I don't see any date in this field at all.
My question is - is this functionality going to be included in any future 6.x release at all and if not what's the best way of implementing it?
Thanks.

subscribe

subscribe

Subscribing

sub

subscribing - have the same issues/requirements

I also have run into this requirement in the same context as others - historical records which may have varying granularity in their known dates.

In the meantime I'm considering the somewhat makeshift approach of a free text 'date' field, from which I programatically try to get at least a year value using PHP's strtotime() function. This year would be inserted into a proper date field, so I can have year-based views.

I'd welcome any other suggestions.

hdcwebteam: if you are seriously considering a free text date field, you might like to look at #108.

roymp: Oh very nice work! Missed it skimming the thread, but that's an elegant approach and well described. Thank you for sharing it.

i think that because my bad english, i dont understand the options on Date.
in the documentation http://drupal.org/node/262066 they say that you can use Date (ISO Date) and Datetime to allow 0 values on the database.
i have tried both, and if a value is not set, i get 1 instead of 0.
then i found this issue, so... isn't permited by the cck field?

thanks for any clarification :)

i am trying to apply the patch...
i have before applied a patch by hand and one by console and both worked.
this time i get errors...
i dont like to make changes on modules but i really need this feature :)
i have:
Date 6.x-2.7
Drupal 6.20
PHP 5.32

date_api.module : everything ok :)
date_api_elements.inc : Hunk #2 FAILED at 136 , Hunk #4 FAILED at 206.
date_api_ical.inc: Hunk #1 FAILED at 392.
date.module: Hunk #1 FAILED at 347.
date.theme: Hunk #1 FAILED at 279.
date_admin.inc: Hunk #1 FAILED at 245, Hunk #2 FAILED at 359, Hunk #3 FAILED at 486.
date_elements.inc: Hunk #1 FAILED at 135, Hunk #2 FAILED at 207, Hunk #3 FAILED at 282, Hunk #4 FAILED at 487.
date_popup.module: Hunk #1 FAILED at 144, Hunk #2 FAILED at 174, Hunk #3 FAILED at 282, Hunk #4 FAILED at 374.

now i am going to try by hand... if i am successful, i will tell here...

edit: since i dont know to do a patch and now i have not the time to learn, i write here wat i found:

date_api_elements.inc : Hunk #2 FAILED at 136 , Hunk #4 FAILED at 206. (the lines where a little after)
date_api_ical.inc: Hunk #1 FAILED at 392. (it was already made)
date.module: Hunk #1 FAILED at 347. (lines after)
date.theme: Hunk #1 FAILED at 279. (not anymore the same function (if (date_has_time($field['granularity']) && $min_comp && $max_comp) ) but i dont need the 'all day' event, since i need to cataloge dates, no events)
date_admin.inc: Hunk #1 FAILED at 245, Hunk #2 FAILED at 359, Hunk #3 FAILED at 486. (some lines later)
date_elements.inc: Hunk #1 FAILED at 135, Hunk #2 FAILED at 207, Hunk #3 FAILED at 282, Hunk #4 FAILED at 487. (some lines later)
date_popup.module: Hunk #1 FAILED at 144, Hunk #2 FAILED at 174, Hunk #3 FAILED at 282, Hunk #4 FAILED at 374. (many lines later and this diference
$id = date_popup_js_settings_id($element['#id'], 'datepicker', $settings); //new version of module
$id = date_popup_js_settings_id($element['#id'], 'timeEntry', $settings); //in the patch
but i add the line
'#default_value' => (!empty($element['#value']['time']) || !empty($edit['time'])) && is_object($date) ? date_format($date, is_array($date->granularity) ? date_limit_format($time_format, $date->granularity) : $time_format) : '',

then i tried and:
got
Parse error: syntax error, unexpected '}' in /xxx/sites/all/modules/date/date_popup.module on line 436
i look the code and delete the } .

Parse error: syntax error, unexpected '}' in /xxx/sites/all/modules/date/date_api_elements.inc on line 143
i look and change " ," into a ", $granularity);" (the original was like that)

i can make fields but when i preview them, the data is lost.
if i save, it is lost too.

if i put the same as David Lesieur, if i preview writing only the year, the date in the preview is ok but in the field on the form gets changed.
if i dont do preview (what i need for the project), it gets saved as a number.
if i try 2000-00-00 it tells to me that it is invalid.

but i tried :)
now i go to make 3 date fields to be able to do what i need...
if anybody can debug, it will be great since this feature is very much needed by the community.
thanks to you all :)

hello again :)

at the end i will do 3 dates fields for choosing among year/year+month/year+month+day.
this will make the search engine slower but i dont find any other solution.
ideas are wellcome

KarenS, the module is great :)
i understand that this implementation is a small feature inside it.
but this is the only module to integrate dates on a cck field and some of us dont use date for an agenda but to save dates that can be searched using your tool.
many times, in this context, the fuzzy granularity is needed.

for this cases, i would suggest that, since David Goode has done a patch that works on the 6.20 version (but in the preview) for

Field type: Date
Widget type: Text Field with custom input format
Input format (date()-style): Y-m-d
Granularity: Year-Month-Day

it could be integrated in the module as for an option only with this options (maybe you show only the option when it fits and say it on the documentation...).
i am sure that all of us that are waiting for this implementation would be very very happy.
and if you change the code with new versions, the David Goode patch work will not have problems like in my case with preview.

thanks you all that make this wonderful tools :)

subscribe.

I think there are two parts of the problem:

1. Fuzzy granularity, where only the more granular parts are omitted. This is already implemented, but the granularity has to be chosen when the field is defined, and can not be chosen later (per value). The solution is to allow choosing a minimum and a maximum granularity on field definition. (*)

2. Periodical datetime (see #15), where less granular parts are omitted. This starts with omitting the date and only specifying the time, but could become arbitrarily comlex (every Sunday 15:00, first full moon of April etc). So..
2a. Time without a date
2b. Minute without hours, weekday without month and year, and anything one could think of.

I think it would be reasonable to focus on the first issue, 1.
2a is something to consider, but 2b is just totally out of scope, and should be implemented with separate modules.

EDIT:
Added some more text to (1.).

(*) There is a semantic or "philosophical" difference between date-only values and date-time values.
Date-time is usually understood as an exact moment, even if the granularity is just hours. For instance, we think 20h as being the same as 20:00 or 20:00:00 or 20:00:00'000.
Date-only should rather be understood as a time interval. 2011-04-26 can be read as "the 24h interval between 2011-04-26 00:00 and 2011-04-26 24:00.

By not giving a timezone, the 24h interval becomes a space-time rhomboid. See
http://drupal.org/node/269813#comment-4391880
Actually this also applies to datetime: If you don't specify a timezone (and don't assume a default time zone), then 20:00 has to be seen as a stepped space-time surface.

+1 for donquixote's view #154

we might add the simplest special case
1a. date without a time

It seems that date without time did work in Drupal 6 (with granularity set to minutes) but it no longer does in Drupal 7. Why the loss of functionality?

Phew, I don't have time to read through 156 replies at the moment, but I'd very much like to see fuzzy date granularity in 7.x-2.x. To me that means being able to enter either "yyyy-mm-dd" or just "yyyy-mm". Currently, it's possible to enter "yyyy-mm", but this gets converted without warning to "yyyy-mm-dd" on the backend, which is a rather bad UX. I'd be happy to test any patches.

subscribing

Hi asb (#159),

I'm not sure if you saw my post at #108 which includes a downloadable White Paper that I believe deals with most if not all of the issues that you and others here have raised.

This paper is all about fuzzy date handling in a comprehensive adaptation of the ISO 8601 standard: Fuzzy dates in military history databases - FZY-D, a proposed variation on the ISO 8601:2004(E) datetime format.

I'm now more experienced in Drupal than when I wrote the original post and about to start work on developing a fuzzy date field type module for D6 and D7, based on the thinking in that paper (some minor improvements since then), precisely because there is still no other solution that works for the military history data that I need to manage.

(IMNVHO) I don't believe that this can (or even should) be implemented within the Date module because the requirements and characteristics of fuzzy dates are so far removed from those of conventional dates but, as always, I'm very happy to hear different views on this because it usually ups the quality of the end product.

If I may be somewhat immodest, another contributor here (#150) described the paper as "...an elegant approach and well described".

Nice. I would not mind to see this in a separate module. To the contrary, separate module usually means we get there faster.

Also, if you are into theory, you might want to check out the stuff I wrote about understanding dates as time intervals (#154).
(I have not read the paper yet, sorry..)

Thanks donquixote: don't know how I missed your #154.

Rhomboid space-time eh? Scary! ;-)

When I originally wrote the paper I had been trawling for "fuzzy dates", but later I discovered more material under "temporal intervals" and in particular James F. Allen's 1994 paper Actions and Events in Interval Temporal Logic.

This introduces "Allen Operators" which are remarkably like mine and show that I was merely re-inventing a type of wheel. D'oh! He gets into recursively considering the upper and lower boundaries of an interval (the start and end of a date-time period to the rest of us) as intervals themselves. It is an interesting and thorough paper though which made me rethink or extend certain bits of my approach.

There was another paper in 1998 by Martin Doerr et al: Implementing a Temporal Datatype but, if I recall correctly, this was a doomed attempt to force fuzzy date data into a numeric format.

Notwithstanding these very technical and theoretical approaches, in my paper I've tried to be pragmatic and flexible, based on several years of experience of coding fuzzy date logic and managing the resulting data.

Your point about having a separate module is well made. I'm very aware of the (feature-rich) complexities of the Date module, and although there's now a new date data type that gets away from many limitations of the old Unix/Oracle etc date types, I think that a fresh clean start that tackles the date fuzziness problems head-on is probably a winner for many situations.

subscribing ... I need this too

Has anyone got the patch to work with D7?

subscribing. Any updates on this for D7?

The last commits on the David Goode's GSOC date module branch go back to August 2010. Unfortunately it cannot be used with more recent versions of Drupal 7 due to the API changes.

Subscribing. I have a site that lists concerts; concerts in the near future have the date and time determined, but concerts further out have only the date finalized.

Just for the record, I've tried the patch #114 against date-6.x-2.7 and does not apply (and it doesn't work either).

Can someone who's been working on/following this re-write the summary? It's a bit hard for a newb to get their head around the mass of comments, and figure out what's going on and what's likely/unlikely to happen..

Also, I have a need for the possibility of an end date without a start date (start date is unknown). Would this feature come under this issue, or should I file another?

Take a look at http://drupal.org/project/partial_date

I'm going to mark this fixed since there is another module trying to provide this functionality. I'll add a link to that on the Date project page.

For the interested subscribers, partial date is still a very young module, some important bug fixes to be committed as of this morning. It was hacked out over a 10 hour window for an estimated 2 month long project that has a 3 week deadline :(

I didn't do too much research, but it follows the ideas that I have seen quickly browsing this thread. I'm using a float timestamp and individual integer fields for the granularity, (plus a couple extra fields).

It supports fairly much any date, reducing FROM values to the lowest legal value when calculating the timestamp or the greatest allowed values for the TO values. For the year, this means 9999999999999 BC or 999999999999 AD (ie: at the very start or end of a sorted list), Jan or Dec for months, 1 to [28|29|30|31] for days, etc.

Please report any issues (I'm sure that there will be a few over the next couple of weeks)

Happy testing and any help (especially patches) would be greatly welcome!

KarenS: Does that mean that Date definitely will not be implementing this, or would you consider merging Partial Date into Date module at some time in the future?

Whether or not this gets merged in in the future depends on where it goes and what its maintainer wants to do with it. I'm not opposed to the idea, but for now it's better to have it somewhere where someone else can focus on it.

The only issue I have with the new module is it requires a new field versus adding "fuzzy granularity" to an existing field. For sites with a lot of nodes, this is a pain in the butt to migrate to these new fields for a module just starting out!

I totally understand wishing this to stay on another module for now (who has the time to chase every feature?), but some fuzzyness in the main date module would certainly be welcome...

Rereading the thread now...

I guess, the solution could be a drush command to bulk convert field data.

I would add a feature request on that module's issue queue to provide an conversion option to switch fields of type date, datetime, or datestamp to the new field. It could also be a drush command, but either way the code would logically live in that module.

You'll want to wait until it has stabilized before you do anything anyway, so I would keep an eye on the code and help ensure it works correctly, then help provide an upgrade path.

I have a similar issue. We would like to some posts with only Year and Month values (i.e., leaving the day value as blank) while others with Year, Month, and Day values. Whenever we tried to input only Year and Month values, the whole date field became blank.

Can anyone help?

Changing the status to better reflect what KarenS has said:

Whether or not this gets merged in in the future depends on where it goes and what its maintainer wants to do with it. I'm not opposed to the idea, but for now it's better to have it somewhere where someone else can focus on it.

The problem isn't fixed in this module, and the partial_date module is for D7 only, and is also in Alpha. I'm not saying this should be fixed, just think its misleading to mark it as fixed when the feature hasn't been made available.

(I'm looking at this issue because I just had client request dates with compulsory years and optional months and days on a D6 site using Date. I've told them it's not currently possible.)

waiting on this big feature

Would also love to see this feature implemented.

As the programmer that pulled the short straw, I don't think that it would be feasible without dropping both DB and PHP native date support which would be a massive drawback to this project as a whole.

After trying partial_date module I've found this discussion but it looks there isn't a complete solution yet. Partial_date module looks interesting but it's not well integrated with views like date module, eg: exposed filters for date components doesn't show year/month/day ranges but the user have to manually write a value. Adding this feature do Date module would allow to have a better integration with the existing Drupal modules. Thanks.

I really believe it's also a bug in 7.x. We should fix it in 7.x if it's the case.

We 'solved' this problem partially (for historic newspapers) by storing two dates: start date and end date:
e.g. when only the year and month are known, start date is YYYY-MM-01 and end date is YYYY-MM-31, meaning that the date should be somewhere in between. The output of the fields is then changed in the theming layer. When start date and end date are equal, shown only the start date, otherwise it shows 'between start date and end date' (an example can be seen on http://warpress.cegesoma.be/en/node/39638).

I would agree not having flexible granularity for input in the Date widget can be considered as a bug. Really, what else to use this module for, if not for flexible Date widget? PHP can do date operations pretty well, but flexible widget would be of value for Drupal. I would have to abandon using this module for date entry (again - not seeing what else to use it for then) because of lack of this functionality.

Updated priority to major to reflect the community interest in this functionality (and many believing not having it is a bug, me included).

The fact that this issue has not been solved for more than five years (not counting month, days, hours, etc ;-) ) leads to a lot of nasty workarounds like using two date fields and one computed field.

I think there is a way to solve this issue.

1.) Add "optional date attributes" in the field settings, e.g Hour and Minute.

2.) Add "granularity" (or alike) in the field storage per field entry.

3.) Use "granularity" in the field display settings to output the data.

This way all existing data can be used as before and there would be an easy upgrade way.

I must say that I'm also amazed that this has still not been resolved after all this time. I offered a completely alternative way to comprehensively manage fuzzy dates and granularity in 2010 (which has been comprehensively ignored ever since :-)

Here is version 2.0 of that "Fuzzy Date Management" White Paper, offering a revised and updated...

"rich vocabulary for precisely describing imprecise dates".

It is a proposed variation on the ISO 8601 standard datetime format, and would appear to address most, if not all, of the issues raised over and over again in this thread. It may not be possible to incorporate this within the Date module, because it takes a fundamentally different approach from regular date management, and I'm proposing to develop a separate Fuzzydate Module, having already developed and thoroughly tested the logic (over many years) in a different language, and then used the format extensively in an offline database.

Clearly no-one is getting anywhere with Plan A. Perhaps it's time for this Plan B?

[ps: I discussed this with Dries at DrupalCon London in 2011, and gave him a copy, but never heard back]

For me it still remains a bug. It was something available in Drupal 7s date field and was a very widely used feature. Implementing the date field without the option of that granularity was either done on purpose to cripple the date field in core or there was no evaluation done on what features were needed. The current functionality of the date field is pretty useless. It can't be used for calendars without starting or end time. It can't be used for birthday calendars or in calendars where time is not an issue. Think of all the people filling in calendars and always are requested to fill in the time. This is a total UI and UX bug and should have been fixed before the release.

Really frustrating, cannot make this happen, the patch won't apply.