*** btami has joined #gnuenterprise good morning *** kilo has joined #gnuenterprise *** reinhard has joined #gnuenterprise good morning all good morning *** johannesV has joined #gnuenterprise good morning *** yure has joined #gnuenterprise *** yure has quit IRC *** derek_ has joined #gnuenterprise *** derek has quit IRC *** lekma has joined #gnuenterprise hello all i need some help to understand dates ? *** reinhard has quit IRC what kind of help do you need ? i have some strange things going on between db and ui as i understood the way it works user ---[LOCALETIME]--> rpc client ---[UTC]--> rpc server ---[?]--> database user <--[LOCALETIME]--- rpc client <--[UTC]--- rpc server <--[?]--- database so i'd like to know if i'm correct *** reinhard has joined #gnuenterprise and what is the timezone between db and appserver if there is one and if i'm wrong how can i solve the following pb: user in germany other user in japan records they create must be in correct order in db am i clear? * lekma should go to sleep instead of coding all day and night lekma: there is no timezone handling currently so appserver just takes time values like you give it so if you use gnue_createdate etc it's all in the timezone appserver is running in if you pass datetime values in a store(), appserver takes what you give without any conversion ah ok that would be a feature request then? well, actuall python's datetime.datetime has no 'native' timezone either instead one would have to implement timezone-support if needed as there is just kind of an api (base-class tzinfo) at least that is for python2.3 *** jamest has joined #gnuenterprise *** btami has quit IRC *** kilo has left #gnuenterprise I am not sure I understand what feature you would exactly want converting times values to UTC before storing in the db might not be what most users would expect if you convert them back to locale before displaying i don't see wher is the pb still somebody searching in the db directly via sql might be surprised to find "wrong" values also there might be some problems with searching hmmm..... actually well my pb is with sorting dates if *anybody* did the conversion to UTC and back there is some value is having tables accessable with sql then it would have to be the client, anyway, IMHO for those quick and dirty things where you don't really want to write an application to access appserver to get the right data i would imagine anyway and if I was accessing my tables via something like zope then wouldn't i have to deal with the time conversion as well? if i don't ensure coherence between dates stored in db, sorting means nothing you're crossing timezones? jamest: you run into troubles as soon as your users are in different time zones anyway, no matter what you do reinhard: yes, i realize that not right now, but that's something that could happen but I think timestamp storage is somehting the app developer should determine I tend to agree here I could for example imagine gnue-forms having a parameter "store all time values in UTC" could i pass a timezone string in xmlrpc? i mean will it be acceptable for appserver ? and then forms would convert all time values before sending to db lekma: that's a good question cause postgres seem to behave correctly if i give a timezone info postgres knows datetime values with or without timezone IIRC and stores it internally in UTC, which solves the pb there is a xmlrpc.Date structure used for transporting dates ... but i cant remember wether it's capable of timezones right now I can try to find it in the XMLRPC definition i was reading GDateTime.py but i must admit that i' a little bit lost from the xmlrpc spec What timezone should be assumed for the dateTime.iso8601 type? UTC? localtime? Don't assume a timezone. It should be specified by the server in its documentation what assumptions it makes about timezones. so it looks like you can't pass a timezone there by definition and that we can define, for example, that all dates must be the timezone which appserver runs in well the sepec says iso8601 or whatever and iso8601 do support timezones i'd say that if not defined we should stick with UTC and the client would be responsible to convert it Date values The time value is "naive time", and does not include a timezone. You can either use a fixed timezone in your application (such as UTC), or ship the timezone offset as a separate value. or server localtime but then the server would be responsible to send its timezone from http://effbot.org/zone/xmlrpc-errata.htm lekma: I agree 100% that timezone handling is a missing feature in appserver which would have to be implemented by either documenting something, or some changes in appserver itself, or (most probably) both :) I think it would make most sense to make the client responsible to send only UTC time values to the server that's fine for me but then appserver would have to convert all automatically set times to UTC, too like gnue_createdate etc which currently is in appserver's local time zone ja and I figure there's a whole bunch of other problems we might run into if we look closer, for example the fact that the date part of a datetime value can change when you convert timezones that is the starting point of my pb cause now i send only UTC and assumed UTC was back but then i saw differences betwen days when playing different localetime so here we are so changing your client to convert values to UTC before sending to appserver, and convert back to local time when receiving values, would do the trick for now? that's what it does now my pb is if i look to db using another client i get differences cause i assumed there was some kind of conversion between db and appserver to utc ah so your problem is the time zone difference betweeen appserver and the db? for example i will get different result if i look up dates insinde a procedure not between client and appserver? or if i use a client that converts to and from UTC well if we say the client is responsible to convert, i got no pb now ok would you agree that it makes sense to define it that way? from the client pov but i'll still have pbs if i lookup dates in procedures lekma: what db do you use? yes jamest: postgres cause then the server won't convert to UTC i thought in postgresql if you created the field as timestamp with timezone it defaulted to storing in utc lekma: the dates you get in procedures are already UTC, aren't they? nope, even if they are stored in UTC by pg, they are converted to server local zone when requested there are two possible solutions, i think: we can say all dates and times are converted by appserver to UTC before sending to db or client then everything is fine except that if you use direct access you will have diff or we could provide a way to specify tz if needed for a field they are converted to server local zone <-- change that to "if you provide a tz" wow too fast if you provide a tz pg will store dates in UTC, otherwise it stores what it gets jamest: that's right, but we don't have yet a "datetimetz" datatype in appserver :) ah I think this really needs more thinking also regarding different backends and how *they* are able to handle timezones *** krizz_ has joined #gnuenterprise *** siesel has joined #gnuenterprise got to run bye *** lekma has quit IRC hi hi siesel talking of timezones lekma goes, siesel comes :) hello seems like i drove lekma away ;) hi reinhard, krizz can i generate the pot file from a svn checkout? Currently I would prefer we would be back in the middle age ... and if not what language file is the most updated? I mean, when the earth was a plate, and there were no time zones, ... siesel, and women couldn't vote :) siesel: and only 2 times day, night rolf krizz_: you can in po directory that would 've been cool, I just don't know where to hack on then ;) make gnue-common.pot (or whatever) siesel: you know that's why the roman empire died in roman numbers, there is no concept of 0 so they couldn't indicate success for their C programs lol lol savages! krizz_: does that mean greek translations for gnue coming up? (that would be great) btw. krizz, does mysql works fine for you now? oh yes the problem had to do with the UI in wx didn't work in wx26 worked partly gtk perfect tried in windows and ubuntu.. but i got confused at the end, so i'm not sure the behaviour in each case great, so the second mysql patch didn't break your setup. Cool. no it didn't... :) reinhard, i think greek for gnue-common and gnue-forms will come really soon krizz_: you might wanto to wait a little for forms although i'm not sure if any greek will bother using them (atleast in gnue-common) because it's undergoing a partial rewrite error messages are not really helpful when in greek :) krizz_: gnue-common contains a lot of general error messages etc that are presented to the end user some of them are :) so i'll just give a try in common? and wait for forms *** johannesV has quit IRC *** johannesV has joined #gnuenterprise *** jcater has joined #gnuenterprise can i ask another thing? in forms when you click Clear Form, is it ok that all buttons get disabled except from Delete? sounds like a bug to me what the correct behavour should be? wait... when you clear the form does it bring up an empty form? yes it does or does it clear out changes made to the current record and show the current record again ? it brings up an empty form I would think delete should be disabled on an empty form with no changes *** siesel has quit IRC *** lekma has joined #gnuenterprise back siesel!!! come back Kinda like clark kent and superman, or peter parker and spiderman hmmmmmm :) i just updated my svn. so that's the case I press to insert a new record i type something and the i press clear form the form clears and only delete,jump to, search and print are enabled mysql4.1, gtk well siesel, if you read this: there's an undocumented date function that might help you for date displaying, see https://bugzilla.mozilla.org/show_bug.cgi?id=291494\ and i'm working on converting my code completely back to javascript std objectes so that you may use it in your ff extension and it can one day be ported to other browsers >> make gnue-common.pot reinhard, this doesn't do anything ... No rule to make i'm trying to make an empty .pot file (like the one in stable release) so i can start translating with the most recent file from svn krizz_: yes, that's because I talked nonsense the command is make update-po *** yure has joined #gnuenterprise :) yeah!!! That should do the trick! bbl *** reinhard has quit IRC *** derek_ has quit IRC *** sacha_ has quit IRC *** derek has joined #gnuenterprise *** klasstek has joined #gnuenterprise *** krizz_ has quit IRC johannesV: you around? what is the theoric max of a number(2)? 100, is it? i'd say 99 no actually it depends a bit on the backend-driver (Behavior) since it determines what to create for a number having two digits cause when i run sample.gcd address_children is a number(2) but the db max is 32768 look into DBSIG2.Behavior.number () yeah for a postgres that is a smallint it's not really coherent with the others (up to 4 digits it gets a smallint) like number(4,1) not every backend supports the same types brb ok what do you mean with coherent ? you mean appserver should actually check for the range defined ? or should readgcd (or readgsd in fact) create a check-constraint depending on the length/scale defined ? well can't it create a numeric(2) in pg? that at least would be what is expected? you mean instead of mapping to the predefined types ? hmm, i don't really apprehend all the consequences but it seems logical... or maybe is there another way to ensure that data didn't go over max or below min actually it isn't very hard to do (for postgres) although this would make all numbers (even integers of small size) numeric values. (using up more space and having a slower performance) see http://www.postgresql.org/docs/7.4/interactive/datatype.html#DATATYPE-NUMERIC (as an example) actually one could use a check-constraint, bot not all backends support such constraints so there should still be a possibility to have integers instead of floats, shouldn't it ? e.g. for autoincrements or foreign-keys or just other sequences ... *** reinhard has joined #gnuenterprise lekma: you still here? btw, where are all the commit mails ? ok, i'm off for today ... have a nice evening ... *** johannesV has quit IRC for the logs I've documented today's discussion about timezones as a wishlist item for appserver in roundup, I understand that there's no immediate need to solve this now http://www.gnuenterprise.org/roundup/gnue/issue94 also documented the request for appserver checking number(2) to be not higher than 99 instead of depending on the backend: http://www.gnuenterprise.org/roundup/gnue/issue95 *** jamest has left #gnuenterprise damn, I'm confused since when does "print" in python encode strings to the current locale?? last time I looked print tried to encode to 'ascii' no matter what local you ran hmmm... it didn't work in 2.1 *** sjc has joined #gnuenterprise so, the TODO list is in roundup now is that right? yes at least for those tools that used ROADMAP.in okay there was one tool that had its own non-ROADMAP TODO file can't remember which that was but I didn't touch that as I wasn't sure how current it is anyway ah both navigator and reports ah both are likely invalid now yeah like from reports TODO * DOCUMENTATION!!!!!! I wouldn't believe you still seriously consider that ;-) lol so *** jamest has joined #gnuenterprise what is the difference between feature and wishlist? so far I have handled it like feature = already decided that we will do it, probably in next version or so jcater: its context of submitter ;) wishlist = not yet working on it feature == something submittor requests and plans on adding wishlist == somethign submittor requests and hopes someone else will add FWIW, I can agree with many stuff it was just an idea how to use I don't care feature == you can count on it I was just wanting to be consistent wish == noted so maybe we'll get back to it I moved everything from ROADMAP to wish except those things we are really working on now, you should define "working on" :) lol will be in next release *** krizz_ has joined #gnuenterprise reinhard: dumb question how do I show all "gnue-designer" issues? topic = gnue-designer that's easy searching for "gnue-designer" only shows issues where "gnue-designer" shows up in the description click on (edit) right to "Your Queries" set all queries to "include" and then you can click on the predfined "gnue-designer" query :) cool because the Your Queries box was empty it wasn't registering with me that it was even there :) does it support having all new issues assigned to a specific topic to default to being assigned to a particular person? erm.... would have to look that up not important.... can you create a new issue in www and assign that to me? :) well problem might be that you can assign an issue to more than one topic true (while we have more or less silently agreed to not do this) it topics are on a list though right? s/it/the right iirc there is a config option to flip that to a dropdown might be good to do that if you find that option :-) i can look tonight if I remember :) what is a Superseder ? something you must fix befor you can fix this (is my understanding) oh hmm so, if a bug is a duplicate of another one what is the proper way to handle it? I'm not seeing a "Duplicate of" or "Not a bug" option just "Resolved" with a note? we might want to introduce that the administrator can introduce new status at will, AFAICT ah like we could also rename "feature" to "feature in next release" to make things clearer internally it's all handled with numbers or at least "planned feature" then again.... is there a way to make some of the statuses only be assignable by certain people? i.e., I don't need derek going in and putting in Planned Features into gnue-designer :) also, I would like to see "resolved in SVN" vs. "released" only wishlist items there might be a way to not let "normal" users assign a priority at all then you look through all designer issues and assign priorities * jcater is going to try to make it a habit to look at roundup the email gateway might help with that :) * jamest notes jcater didn't say he'd take action on the things he sees in roundup jamest: for the time being do you remember the admin password for roundup? jamest: as long as I have "reassign to:" I'll actively use it too I think you should be able to give administrator role for example to jcater and me reinhard: I have mixed feelings about not letting normal users assign any initial status as it would be nice to let them distinguish between "bug" and "wishlist" but then again, if the choice is only between them being able to pick any status, or no status at all I think I'd lean towards the latter I have no idea what choices we have why not? you have nothing better to do, right? roundup is so highly customizable that I don't even know what you *can* customize but given the fact that it's written in python, I guess you can do pretty much :-) and I am seriously planning to play around with it a bit reinhard: it should be on a sheet at home but off top of head no so it might even show results if you document your wishes :) jamest: ok, nevermind give me a sec and I'll short it out :) ok, you should be admin now jamest: thanks yes, I'm admin now already renamed "feature" to "planned feature" how about "bug" to "derek's mistake" lol *** krizz_ has quit IRC reinhard: are you editing roundup atm? yes already fixed the traceback again :) lol trying to change topics from a list into a dropdown i went to save a change to the topics and it told be the file had changed on disk :) oh what did you change? what is roundup? reinhard: i was going to change the topics section our bug/feature/issue tracking system had changed it oh http://www.gnuenterprise.org/roundup/gnue ok but vi aborted the save as you beat me to it we just switched to it thanks you can overwrite it, my change didn't show the desired effecct oh ok mine didn't work either maybe we tried the same thing ;-) not quite i thought in the python context menu(height=1) flipped it to dropdown issue = IssueClass(db, "issue", assignedto=Link("user"), topic=Multilink("keyword"), priority=Link("priority"), status=Link("status")) I think it's the Link vs. Multilink wait