This patch expands on the core date handling capability and lays some groundwork for further expansion in the future:
1) Add new date.inc with basic date and time handling functions consolidated in a single file.
2) Add new date.library.inc, an optionally included file which makes more date functionality available.
3) The new functionality includes expanded date ranges to handle dates from the year 100 to the year 3000 by included a 'Drupalized' version of ADODB date library. This is designed to use core date functions where they will work, and include date.library.inc with expanded functionality to handle dates outside the normal date range.
4) format_date() and format_interval() are moved from common.inc to date.inc to keep datetime functions in a single place.
5) format_date() is adapted to work with the expanded date range capability added by the date.library.
6) Date.library.inc also includes a 'Drupalized' version of the PEAR Date Calc library. This file must be included when needed, but will allow the ability to find things like the last Tuesday in March of 1959. The date calculations will work for the expanded date range (pre-1970 and post-2038). No core modules are using that kind of functionality now, but making these functions available in a central location will allow both core and contrib modules to start adding them in.
7) The basic date.inc also includes simple functions to return an translated array of month and day names (both full names and abbreviations), to make that available as a core capability. Currently we have many contrib modules creating their own methods of doing that.
8) As other improvements are made to core date and time handling (like improved timezone handling), they can be consolidated in these new file locations.
I'm having trouble getting the Windows line ending out of the patch, so I hope it will work correctly :-)
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | date.test_.txt | 5.6 KB | karens |
| #7 | date_8.patch | 83.54 KB | karens |
| #6 | date_7.patch | 94.3 KB | karens |
| drupal.date_.patch | 81.61 KB | karens |
Comments
Comment #1
moshe weitzman commentedsubscribe ... this is great functionality. the pre-1970 limitation is so lame.
Comment #2
dww+1 from me, too. Don't have time now for a thorough review of the patch or testing, but I'd love to see this in core and will try to make time soon.
Comment #3
m3avrck commentedThis would be awesome!!!
On a super quick review, I would suggest the following functions date_minutes() and date_seconds() have an optional interval parameter to specify whether these should be generated each min/sec, every 5 min/sec, every 10, etc... That would be super useful when date interfaces can be improved by using close 5 or 15 min approximations :-)
Comment #4
karens commentedI think the interval parameter for minutes and seconds makes a lot of sense. I also want to make a few fixes to the patch to avoid some problems I found in the gmmktime() function (see http://groups.drupal.org/node/4838 for more about that). I'll try to get a new patch rolled with these changes.
Comment #5
rconstantine commentedI just downloaded your patch and will review it. As I'm sure you guessed, +1 from me too.
Comment #6
karens commentedI found a few things to tweak, added the increments to minutes and seconds, and created a test script. First, here's the patch.
Comment #7
karens commentedBlech, windows line endings got in there again, another try.
Comment #8
karens commentedAnd here's a test script. Include this somewhere and run date_test().
Comment #9
karens commentedI'm moving this into the 7.x branch. It will need to be reworked from scratch at that point. In the meantime, I'm working on adding this to the Date API module to make it available to other modules in 5.x and 6.x, see http://groups.drupal.org/node/4979.
Comment #10
chx commentedThis is something where PHP5 could shine.
Comment #11
alexanderpas commentedmay I point everyone towards:
ISO8601: Numeric representation of Dates and Time
Wikipedia: http://en.wikipedia.org/wiki/ISO_8601
Summary from ISO: http://www.iso.org/iso/support/faqs/faqs_widely_used_standards/widely_us...
Full document (zip-pdf, 228KB): http://isotc.iso.org/livelink/livelink/4021199/ISO_8601_2004_E.zip?func=...
how about a varchar field that simply stores the ISO date and/or time
Comment #12
arhak commentedtime for D8, right?
PS: also an old (2006) thread http://groups.drupal.org/node/731
Comment #13
marvil07 commentedNow that drupal 7 requires at least php 5.2.5, and now that KarenS's date project has an 7.x-2.0-alpha4 published. Does this issue becomes "Adapt date project date_api submodule to get into core and use it to handle all date/time information for core"?
Comment #14
sun@KarenS: Is this still relevant?
Comment #15
moshe weitzman commentedAFAIK, the latest discussion on this is at http://groups.drupal.org/node/221229 and spinoff storage discussion. We could use help here, if anyone is inspired.
Comment #16
karens commentedThe topic is relevant, the patch is not :)
Marking it back to active since the patch is pretty useless now.
Comment #17
sunApparently, you're not on #501428: Date and time field type in core yet, so I'm not sure whether you're aware of that issue. ;)
In light of that separate Date field type module in core issue, this issue seems to focus on generic/low-level date handling functions only?
Comment #18
karens commentedI didn't know about that other issue. I don't think there is any way to have a date field in core without some sort of API to go with it, and I am assuming the API will be a part of any attempt to add a field. We don't have to have two issues, one is probably enough until there is enough work done to propose a patch.
So I'll mark this a duplicate of the other and start tracking that one one.