The date and time formats don't follow the formats I've set in /admin/settings/date-time, both on the week view and in the time field on the create/edit pages.
On the edit form it's in 24 hour format when I've selected am/pm (12 hour). In week view it's (roughly) DD.MM.YY instead of MM.DD.YY
Using Drupal 6.13, Date 6.x-2.3
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | simple_reservation-date-formats-536448-0.patch | 5.97 KB | notzach |
| #6 | simple_reservation-date-formats-536448-5.patch | 5.86 KB | notzach |
Comments
Comment #1
jochen wendebaum commentedI haven't thought of that yet and will try to see what is able to do with the date module.
Comment #2
jochen wendebaum commentedPlanned for Version 1.2
Comment #3
cmoore commentedAny chance of this getting fixed? I've just come across this module and would really like to use it for airplane reservation, but the DD.MM.YYYY date format is going to make it really tough.
Comment #4
salvisAnyone up for doing this?
Comment #5
notzach commentedWe're looking at using this module to handle some room scheduling for one of our colleges and this is something that would be some really useful functionality. So, I've taken some time and put together a rudimentary patch for this. I've added 2 fields to the admin page and variables for the time and date formats.
I've also changed most of the date() function calls to use the format_date(). I can take that out if you guys are all about the date() function, but the format_date() is more drupaly.Checkout #536448-6: Date and Time formats not followedI'm also looking for direction here, is there anything specific anyone would like to see? I'm already looking exposing custom formats from the date and time formats admin page. I also haven't finished trying to use custom date formats with the adding reservations page.
Comment #6
notzach commentedOkay, so I've went back to using the date() function to generate human readable dates. The attached patch is generated against the 6.x-1.x branch and has been tested with 6.22 and 6.25.
Comment #7
salvisI'm not sure how much interest is left in D6...
Comment #8
emilianodelau commentedHas this patch been integrated into a new version of 6?
Comment #9
salvisNo.
EDIT:
Due to how the project owner has set things up, no new versions are ever created, even if a patch were committed.Comment #10
jochen wendebaum commentedThe "project owner" is very sorry about how things are, I am really. This is due to priorities and time issues.
I am openly searching and very thankful for help, and very thankful for the help I got from you, salvis.
Any suggestions on how I can improve things (except spending too much time from my side) are very welcome.
It would probably be the best for everyone's frustration levels to delete the project entirely. Or someone else takes over the project.
Jochen
Comment #11
salvisOh, actually my second statement in #9 is not true — I'm sorry about that. That was an old frustration acting up. The D6 version seems to work reasonably well now and it would be a pity to delete it.
There are snapshots, they're just not exposed on the front page. How about making them visible?
As for the patch in #6, no one has cared enough to review it, that's why its status is "needs review".
Good project management dictates that all commits are done on the latest version first. Fixing things in D6 and not in D7 makes little sense, because they'll pop up in D7 again sooner or later, causing double work.
I'm not sure how feasible SR is for D7. Exposing the snapshot would get some feedback and maybe draw in some help.
Are you the "unknown" contributor/committer in the repository, Jochen? See http://drupal.org/node/1022156 for how to fix that.
Comment #12
NiklasBr commentedeven though Drupal 6 probably has less than 12 months of official support left I wonder if if could be possible to move from date("d.m.Y") which this modules uses to Drupal's standard format_date() function?