[libdb-develop] =?UTF-8?B?W2ZlYXR1cmVdIERhdGUgUmFuZ2VzIGFuZCBEYXRhYmFzZSBNYW5pcHVsYXRp?= =?UTF-8?B?
Status: Inactive
Brought to you by:
morbus
From: <mo...@di...> - 2004-08-24 22:28:42
|
Project: LibDB Version: cvs Component: Code Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Morbus Iff Updated by: Little Nemo Status: active Regarding this post: One can't reasonably assume that a periodical/serial with a publication date of Nov/Dec actually took 2 months to produce, so why not simply assign the publication date as 2004-11-01? The publication couldn't have been produced any earlier right? As for Spring, why not 2004-03-21 (assuming the publisher is in the Northern Hemisphere)? I just don't think altering the code, much less the db, to get the dates "technically right" makes much sense when one can make a reasonable estimation. I think we need to work with what we've got, and what we've got (I think) is good enough. At least for now. And if anyone truly wants to know "fictional dates" I'm sure they can convert them to "normal" calendar dates. LOTR fans I'm looking at you. Little Nemo Previous comments: ------------------------------------------------------------------------ August 18, 2004 - 19:18 : Morbus Iff There are a few qualms I have with the current data model's date system, and it's all due to implementation, not necessarily bad intent. The intent is innocent: dates should be in the form of YYYY, YYYY-MM, or YYYY-MM-DD. The goal here is to say that a "movie came out in 1997" or, if you know the exact date of theatrical release, "1997-06-02". Same sorta thing with birthdays: you may approximately know that someone was born in "1817" or even in "1817-04", but not the exact moment in time. The almost immediate problem with the above formats, however, is the lack of support for "A.D. 143" or "B.C. 23" (though I hesitate to label that a critical issue.) Technically, "A.D. 143" could be referenced as just "143" (YYY, not YYYY), but I'm not sure the underlying database will support that early of a year - regardless, MySQL would convert a date of "AD 43" ("43") to "1943", which isn't what we want. We'd have to zeropad non-YYYY dates ("0143" and "0043"). This doesn't help us with B.C. dates at all. See also http://dev.mysql.com/doc/mysql/en/DATETIME.html: "The supported range is '1000-01-01 00:00:00' to '9999-12-31 23:59:59'. (``Supported'' means that although earlier values might work, there is no guarantee that they will.)" Irregardless of how early a date is, our current data model expects to receive YYYY-MM-DD and ONLY YYYY-MM-DD - there's no capability for just YYYY or YYYY-MM. After some discussion on a #mysql IRC channel, it appears that the only way to handle ranges (where "1997" is a range of ["1997-01-01" to "1997-12-31"] and "1997-04" is ["1997-04-01" to "1997-04-31"]) is to have two database fields: date_start and date_end. It'd then be necessary in our code to create the ranges ourselves (from a user-entered "1997"). This is the only way to do the "right" thing, with proper database columns, and use of WHERE date/time clauses (WHERE date_start > '2004-04-25' for example). * Is this the "right" thing to do? * What about fictional dates ("Shiresmoon 23")? Affected tables: libdb_work libdb_expression libdb_manifestation libdb_person libdb_corporate_body libdb_events. ------------------------------------------------------------------------ August 19, 2004 - 02:23 : Little Nemo All right, I'll bite. Here's a superfluous oneshot bone-head suggestion. A column in each table to be used as a date modifier that can only be represented as AD OR BC in a pull down menu. WARNING - This would require the user to know the difference between BC and AD. :p I'm not sure what the column should be identified as in the schema however. Perhaps "date_type"? ------------------------------------------------------------------------ August 19, 2004 - 02:36 : Little Nemo Just reread this thread after posting. Using my suggestion would of course alter this: WHERE date_start > '2004-04-25' to this: WHERE date_start > '2004-04-25' AND date_type = 'AD' Oh and insofar as fictional events are concerned, if someone reallly wants them, I'm sure they can convert them to "actual" dates. -- View: http://drupal.org/node/view/10160 Edit: http://drupal.org/project/comments/add/10160 |