Custom format to _enter_ dates

Well, here's what's currently available:

1) the drop-down select list which is pretty highly configurable (year, month, and day can either be textfields or select lists, the hours and minutes can be incremented in various ways, and you can choose whether or not to add am/pm and/or a timezone selector. The only other possible gee whiz thing to add to that would be the ability to re-arrange the fields, but I'm not really up for taking that one on at the moment :-)

2) the js pop-up calendar widget which brings up a calendar display that you can use to select a date which gives users a familiar calendar interface.

3) the plain textfield. I improved on the original module somewhat, since the original required that the input be in iso date format and I switched it around so it would accept anything that strtotime allows. That covers a lot of territory, but not, I realize, various non-american shortcut versions of things. I *think* (not absolutely sure) that you can put date parts in any order so long as you spell them out, just not in shortcut formats -- 8/1/06 is ambiguous otherwise, so the strtotime function assumes it is in the month/day/year format the US uses.

I can see that it would be nice to have some sort of ability to use something like the date format string to indicate that the field should look for input as dd/mm/yyyy then use a regex or something to pull the parts out when the form is submitted. This would probably have to be created as another widget patterned on the strtotime widget. I don't have time to try to create something like that right now (and I never can get regexes working right anyway), but if you are interested and want to try to create a way to do it, I'd certainly be willing to add that feature in to the module. I don't think there is anything else out there that will do this, so I'm not sure what you would use as an alternative, but if you need it and the first two options are not viable for some reason, you might as well take this as an opportunity to create something that works the way you want it to.

If you have other ideas for how to approach it, at least ideas that don't involve me spending a whole bunch of time trying to figure out how to get it to work, I'm all ears :-)

Interesting approach!

The rest of this is just thinking out loud. Jump in with your ideas...

You could use this to grab the separator, too (slash, dot, dash, whatever). Don't need the separator here, but might be handy in other places, i.e. use it to explode text entered in the textfield.

My original idea on the selector was to just change the weight on each element to re-arrange the order.

Will we need the ability to parse the format in more than one place (probably, esp if we want to do something with the textfield format). If so, would it make sense to make a function to rip apart the short format into its parts, then call it whenever it is needed instead of doing this kind of iteration in several places?

It might need to be evaluated over and over for the same user. Should we do it once and store the results somewhere as the user's preferred input format? If so, where?

Would any of these be any more efficient than doing it as you've done here? I'm not sure.

I tested the patch and works perfectly.
I think is a first important step for us not US users.
Thanks.

Dodo

@yched, you're right, users can't set formats. I was thinking when they set their timezones they also were selecting formats, but I see I remembered wrong.

For the separator, I was just thinking about using the first encountered non-numeric item as a separator (which might be a space), I wasn't going to use the dash separating the time. Anyway, that has given me some ideas about a way to make the jscalendar widget more useful by changing the format to something that matches the short date format. I'll play with that when I have time.

The rest was just thinking out loud about trying to keep things as efficient as possible. I'm happy with this patch and I'll try to get it committed later today.

Thanks yched!

getting rid of the italics :-)

I didn't realize you had anything else done. If you've got some things in process, I'll just wait to see what you have.

FYI, I'm in the process of adding a function to convert date() formats to strftime() formats. I strongly considered using striftime() instead of date() in this module in the first place and still think it might be needed in various places. I held back because striftime is so broken on windows and because it didn't match up with Drupal core date formatting. Anyway, my first step is to add a function to do a conversion, then I'll think about where it might be useful to use (one place may be in the jscalendar widget which uses a format that is very similar to striftime).

Thanks for your help!

The new function date_date2strftime($format) has been committed. It will convert a date() format string to a strftime() format string.

Hope I closed the ems

Whew! Thanks dodazzi. I was closing italics, but that obviously wasn't helping :-)

Yched,

Thanks for all this work! I am going to take what you've got and work with it more (and mesh in some recent changes I've made to date views handlers and arguments). I think at least some of this could be committed, but I'll look through it more carefully. And I'd be delighted to get further input when you have time again.

As to the line ending problem you mentioned earlier, I'm trying a new way to commit my changes, so hopefully it will work better. I was using a program to strip windows line endings out before committing changes, but in reading further I think it was actually conflicting with the program I was using to handle the cvs commit and checkout, so maybe that was the issue.

I've been working with this patch and it works great for populating the input selectors the right way. However, you changed the names of the form elements in the selector which completely breaks all the validation and storage of the values. You are creating something that returns this:

Array
(
    [date] => Array
        (
            [mday] => 15
            [mon] => 9
            [year] => 2006
        )

    [time] => Array
        (
            [hours] => 11
            [minutes] => 44
            [seconds] => 49
        )

    [ampm] => am
    [timezone] => US/Eastern
)

while the code used to return something like this:

Array
(
  [mday] => 15
  [mon] => 9
  [year] => 2006
  [hours] => 11
  [minutes] => 44
  [seconds] => 49
  [ampm] => am
  [timezone] => US/Eastern
)

I either have to go through the code and find every place that assumes the latter array structure and change it, or change your $form code back to create the array the validation is expecting. I tried to see if there is some reason why you did it that way and I can't tell that it makes any difference. If that is the case, I'm included to change the $form field names back to what they were so the rest of the code still works. But, if there is some reason you need to change that array that I'm not seeing, I need to go through the code and find all the places that I work with the array and change the logic. Is that altered structure important for some reason I'm not seeing??

I'm getting close now. I figured out the answer to my previous question (the forms api creates better looking html with yched's array than with the plain array). I can get almost everything working now with one exception, and here's where I need some input.

For the jscalendar widget, the input format originally was essentially an ISO date (YYYY-MM-DD HH:MM:SS). The module could take the returned value and make a couple minor changes to turn it into a proper ISO date (and from an ISO date into a UNIX date, if necessary), then validate and save it.

However, if you change the input format of the jscalendar field, it is no longer returning an ISO date, it is returning a formatted date that has lots of different possible formats. I need to find a way to take that formatted date and turn it into an ISO date. We can't use strtotime for this because jscalendar handles dates back to 1900 and strtotime only works back to 1970, and also because strtotime does not recognize shorthand dates in non-American formats.

The function that does this work is called date_jscalendar2iso(). Any ideas on how that function can turn the formatted date back into an ISO date??

Or turn the formatted date into a unix date, but without using strtotime().

The text input works, sort of. It creates a date format that matches the site preference. Since it is advertised as a field that uses strtotime, it already has the 1970 limitation and the strtotime conversion works. But it still has the strtotime limitations, i.e. it will misunderstand DD/MM/YYYY and think it is MM/DD/YYYY.

What I ended up doing is committing the formats functions and the changes to the date selector because those all work. I kept your other changes and commented them out. That will retain most of the work you are doing so you don't have to try to keep a patch up with my changes (and I have some bugfixes to get committed so you would have to start chasing after me). Then, if you want to and when you have time, you can try to keep working on this to get the text and jscalendar fields working.

One change I made is to split your formats function between date.module and date.inc. The way I have things set up, everything that is specific to CCK happens in date.module while date.inc is an API that can be used outside of CCK that doesn't know anything about CCK fields. So I store field-specific format info in date.module, but put the function that analyzes the format string into date.inc because that needs to be available to other date.inc functions.

As you said, there is still work to be done to clean up various other things. As you notice things that need work, why don't you start an issue for them that someone can work on (me or you or anyone else).

And again, thanks for all your efforts!!

Yched, thanks!!

I would really like to get this working, in particular to have 'friendlier' input formats for the jscalendar widget than the ISO date format that everyone dislikes. I'm going to spend some time going through this today.

@yched, I can't get the patch to apply. Can you try again?

I'm using Visual SlickEdit to do my edits and I don't see anything about trailing spaces anywhere, so I'm not sure what to do about that...

Awesome!!! Great job. I really pushed your date conversion functions and tested all kinds of pre-1970 dates and it seems to work fine.

I see a few other things that need to be changed, minor issues compared to getting the date conversions to work. When using a date with am/pm it was putting a colon between the time and ampm (easily fixed), and it does not quite seem to be handling the jscalendar conversion on the timestamp date right. Everything else seems to work great, and I think I can figure out the rest of it.

I also see it is trying to add time to some dates that should not have time, which is unrelated to your work, it was a bug in the original module, so I'll try to get this fixed, too.

Hopefully I'll have something to commit pretty soon.

Found the remaining problem -- a variable with the wrong name in the jscalendar2iso function. Committed these changes to cvs. I'll hold off on committing them to the 4.7 branch in case anyone runs into unexpected problems. The cvs version is still compatible with 4.7, so you can test it in a 4.7 environment. Please report back if you have problems, otherwise I'll commit the 4.7 version, too.

@yched, I owe you a huge thank you for all this work!! It's so nice to have the jscalendar widget using a more normal looking date format.

Date_views.inc has a call to date_jscalendar2iso on line 86.

Need to fix that....

After staring at the code for a while, I have realized I have absolutely no clue how to fix this. :-/

What changes would need to be made to views_filter_handler to get it working with these changes?

(Additionally, what would the string be to select "Last 24 hours"? @P-24H? The documentation isn't very clear on ranges ENDING with NOW().... Also, is there a way to specify the range "TODAY 00:00:00.00 to NOW()?")

Is the "Date Range Argument" documentation in date_views_help() still accurate with this new way of storing dates?

Sorry I couldn't provide a patch, but I don't know this module very well yet... :-(

--Brandon

@bdragon - yes, I missed the fixes needed for date_views.inc. Working on that now. The date range question is unrelated to this issue, but basically the 'period to now' condition isn't yet working, but I hope to add that soon (that's noted in the documentation in the file). All the 'period from now' possibilities should be OK.

These changes have now been committed both to cvs and 4.7.

@bdragon you also asked about using the new format in the jscalendar widget in views. I spent some time and wasn't able to get that working, but just ran across another issue that gave me an idea how it might work, so when/if I get time I'll work on it, but that's another issue.

Oops, meant to mark it fixed.