On 7/13/06, Cory R. King <[EMAIL PROTECTED]> wrote: > - All timestamps stored in the database are set in timezone. > > - Even if they are not standardized, as long as a timestamp has a > timezone and isn't floating than DateTime or Postgres can do the math.
RDBO has no explicit support for Pg's "timestamp with time zone" data type, so all values fed to Pg will lack any explicit time zone identifier (e.g., +02, PST, or whatever). The Pg docs say this about "timestamp with time zone" columns: "If no time zone is stated in the input string, then it is assumed to be in the time zone indicated by the system's timezone parameter" So the server_time_zone should be set to the time zone of the db server machine itself. The Pg docs go on to say: "For timestamp with time zone, the internally stored value is always in UTC [...] When a timestamp with time zone value is output, it is always converted from UTC to the current timezone zone, and displayed as local time in that zone." If I added explicit support for Pg's "... with time zone" data types, I'd imagine it'd be straightforward to simply have the DateTime objects spit out their time zones in the formatted string passed to the db. But AFAICT, the existing Timestamp (without time zone) column class in RDBO should work okay with some care even if the underlying column type is "timestamp with time zone." > ....Sometime I'd like to help polish the documentation. I'm just now > learning all this locale / timezone business and it can get pretty > daunting with all the CPAN modules involved. > > The date handling doc's are scattered over many modules. I completely > missed the stuff you pasted while browsing the documentation. I hate to > think about all the other cool stuff I could be doing, but don't know > about yet! I'd like to add such documentation in an entirely new POD, but I'm not sure of the format. A FAQ? Cookbook? User's guide? Suggestions (and patches :) welcome! > For example, can I get a log of generated SQL queries without setting $Debug > =1 in the QueryBuilder? No, the (undocumented, for now) $Debug variables are the only way to get (most, but not all) generated SQL printed to STDERR. > Maybe I could help set up a more "proper," organized manual like > Template::Toolkit has. The content is all written, it is just a matter > of organization. I'd also like to add some examples that aren't just > "here is how to set up the object in some very abstract way" but are > "here is your $object called in your code and here are the cool, > practical things you can do with it". That'd be great :) I know the wiki is annoying and slow, but it may be a good place to work on this. http://rose.sourceforge.net/wiki/ Or you could post it to the mailing list or just do it in SVN directly (tell me your SourceForge username and I'll set you up). Either way, please use POD formatting only since it'll eventually be bundled with the module itself. -John ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object