IRC logs of #tryton for Tuesday, 2012-07-24

chat.freenode.net #tryton log beginning Tue Jul 24 00:00:01 CEST 2012
2012-07-24 08:47 <sharoonthomas> cedk: ping
2012-07-24 09:17 <cedk> sharoonthomas: pong
2012-07-24 09:31 <sharoonthomas> cedk: just wanted to discuss how time / date time is stored in tryton
2012-07-24 09:32 <cedk> sharoonthomas: as time and datetime
2012-07-24 09:32 <sharoonthomas> cedk: not that :) its about the tz and conversion
2012-07-24 09:34 <sharoonthomas> cedk: from what i see we store localized time based on the system local time
2012-07-24 09:35 <sharoonthomas> cedk: i think it is wrong because it is not always possible to convert for a local timezone time to a different time
2012-07-24 09:35 <sharoonthomas> cedk: i think we should store timezone naive utc
2012-07-24 09:38 <cedk> sharoonthomas: why should it not always possible to convert?
2012-07-24 09:44 <sharoonthomas> cedk: found it :) http://pypi.python.org/pypi/pytz/
2012-07-24 09:47 <cedk> sharoonthomas: that's something else
2012-07-24 09:48 <sharoonthomas> cedk: the issue will be there when the timezone is dst
2012-07-24 09:49 <cedk> sharoonthomas: it is not about convertion
2012-07-24 09:49 <sharoonthomas> cedk: rather if the timezone of the machine tryton is installed has end-of-daylight-savings-time transition
2012-07-24 09:50 <cedk> sharoonthomas: "if you perform date arithmetic "
2012-07-24 09:50 <sharoonthomas> cedk: don't we do arithmetic when the user has a preferred timezone ?
2012-07-24 09:51 <cedk> sharoonthomas: no
2012-07-24 09:52 <sharoonthomas> cedk: so how do we use http://hg.tryton.org/2.4/trytond/file/33363c8c080d/trytond/res/user.py#l58 ?
2012-07-24 09:53 <cedk> sharoonthomas: without arithmetic
2012-07-24 09:53 <sharoonthomas> cedk: can you explain ? i think i missed it then
2012-07-24 09:56 <cedk> sharoonthomas: convertion is not arithmetic
2012-07-24 09:56 <sharoonthomas> cedk: where is the conversion/localisation to the user's timezone done ?
2012-07-24 09:56 <cedk> sharoonthomas: in the client
2012-07-24 09:57 <sharoonthomas> cedk: and the client knows the server's timezone ?
2012-07-24 09:58 <cedk> sharoonthomas: yes
2012-07-24 10:00 <sharoonthomas> cedk: can you share a link to the code where this is done, i will try to check the case where i think the problem will exist
2012-07-24 10:03 <sharoonthomas> cedk: the problem i expect to reproduce is:
2012-07-24 10:03 <sharoonthomas> >>> datetime(2012, 10, 27, 1, 30, tzinfo=eastern).astimezone(pytz.utc)
2012-07-24 10:03 <sharoonthomas> datetime.datetime(2012, 10, 27, 6, 30, tzinfo=<UTC>)
2012-07-24 10:03 <sharoonthomas> >>> datetime(2012, 10, 27, 6, 30, tzinfo=pytz.utc).astimezone(eastern)
2012-07-24 10:03 <sharoonthomas> datetime.datetime(2012, 10, 27, 2, 30, tzinfo=<DstTzInfo 'US/Eastern' EDT-1 day, 20:00:00 DST>)
2012-07-24 10:04 <cedk> sharoonthomas: I don't see any problem
2012-07-24 10:07 <cedk> sharoonthomas: for me, it looks like there are 2 representation of the datetime in tz eastern
2012-07-24 10:07 <sharoonthomas> cedk: did u read the last part of the pytz documentation
2012-07-24 10:07 <sharoonthomas> ?
2012-07-24 10:08 <sharoonthomas> cedk: the problem is that in sometime zone (like US/Eastern) the same time can appear twice
2012-07-24 10:08 <sharoonthomas> cedk: for example, datetime(2002, 10, 27, 1, 30, 00, tzinfo=eastern) can occur twice
2012-07-24 10:09 <sharoonthomas> cedk: and in tryton we would have stored timezone naive date time which is datetime(2002, 10, 27, 1, 30, 00)
2012-07-24 10:09 <sharoonthomas> cedk: from that stored date time, there is no way to distinguish if it was the first 1:30 AM or the second 1:30 AM
2012-07-24 10:09 <cedk> sharoonthomas: yes that's what happen when you use a non-increasing tz
2012-07-24 10:10 <cedk> sharoonthomas: storing the tz doesn't help
2012-07-24 10:10 <sharoonthomas> cedk: which also means that if you localize the time (using any mechanism) to a timezone like UTC/IST there is a 50% chance its off
2012-07-24 10:11 <sharoonthomas> cedk: the solution is we should store UTC (storing tz is NOT a solution)
2012-07-24 10:12 <sharoonthomas> cedk: from an infrastructure point of view this is important again, because if tryton is installed on 2 servers (multi server) and the timezone is different for both servers, then the data is corrupt, but if both store UTC we are safe
2012-07-24 10:12 <cedk> sharoonthomas: set UTC in your configuration
2012-07-24 10:13 <sharoonthomas> cedk: thats the workaround, not a solution
2012-07-24 10:13 <sharoonthomas> cedk: and we already do that
2012-07-24 10:14 <cedk> sharoonthomas: what is your solution ?
2012-07-24 10:14 <sharoonthomas> cedk: here is another article which explains and strongly suggests internally only UTC date times (without timezone) must be handled
2012-07-24 10:14 <sharoonthomas> cedk: http://lucumr.pocoo.org/2011/7/15/eppur-si-muove/
2012-07-24 10:15 <sharoonthomas> cedk: datetime.utcnow()
2012-07-24 10:27 <cedk> sharoonthomas: that's what we do except: the standard tz is configurable and we don't warn user for ambigous datetime
2012-07-24 10:28 <sharoonthomas> cedk: exactly, so if trytond is on a machine in UTC, there is no problem
2012-07-24 10:28 <sharoonthomas> cedk: i think we should issue an advisory note on installation page for current versions, but should we not fix this in a future release ?
2012-07-24 10:28 <cedk> sharoonthomas: no
2012-07-24 10:29 <sharoonthomas> cedk: what about nest ?
2012-07-24 10:29 <sharoonthomas> s/nest/neso
2012-07-24 10:29 <sharoonthomas> cedk: we cannot expect a nest user to change his timezone to UTC
2012-07-24 10:29 <cedk> sharoonthomas: when you use with only 1 timezeone there are no problem and it is better to get local datetime
2012-07-24 10:29 <cedk> sharoonthomas: for neso we don't care
2012-07-24 10:30 <sharoonthomas> cedk: for me, i think this is something the application should take care of, and i think its wrong
2012-07-24 10:31 <sharoonthomas> cedk: i already have a few customers on US/Eastern who now have users in Brazil and shipping times already look weird!
2012-07-24 10:33 <cedk> sharoonthomas: use UTC
2012-07-24 10:34 <sharoonthomas> cedk: yes and also convert dates all across the system (in every single field for it to make sense)
2012-07-24 10:34 <sharoonthomas> cedk: s/system/database
2012-07-24 10:59 <yangoon> sharoonthomas: as you say, UTC for the server is the way to go
2012-07-24 10:59 <yangoon> simply because it is the only timezone which won't suffer from any changes or corrections
2012-07-24 11:00 <sharoonthomas> yangoon: ok, so you think it should go into trytond ?
2012-07-24 11:01 <yangoon> sharoonthomas: there is another problem
2012-07-24 11:01 <yangoon> sharoonthomas: the timezone, the company lives in
2012-07-24 11:02 <sharoonthomas> yangoon: is that important ? may be for the reports ?
2012-07-24 11:02 <yangoon> we creeated for our use a module, which handles conversion of server timezone to company timezone and user timezone to company timezone
2012-07-24 11:02 <yangoon> sharoonthomas: think for contracts
2012-07-24 11:02 <yangoon> they must have a fixed date for the legal beginning etc.
2012-07-24 11:03 <yangoon> think for cron tasks, that should be run at defined dates for the *company*
2012-07-24 11:03 <yangoon> finally the legal entity is the company, it is not important, where the user works
2012-07-24 11:04 <sharoonthomas> yangoon: but can't we use the timezone of the cron user ?
2012-07-24 11:05 <yangoon> sharoonthomas: I think the cron user works with the timezone of the server
2012-07-24 11:05 <sharoonthomas> yangoon: i think the cron problem can be solved with the tz of the cron user, but not sure about the rest of the cases you mentioned
2012-07-24 11:05 <yangoon> which doesn't need to be that of the company
2012-07-24 11:05 <sharoonthomas> yangoon: agree
2012-07-24 12:04 -!- smoldersan_(~smoldersa@85.26.85.148) has left #tryton
2012-07-24 15:29 -!- kpouget(~vienin@mtl93-4-212-194-254-51.dsl.sta.abo.bbox.fr) has left #tryton
2012-07-24 15:37 <rhubner> Hi nicoe
2012-07-24 15:38 <nicoe> rhubner: hello
2012-07-24 15:41 <rhubner> nicoe: I'm on vacation now ... I will finish everything before the deadline! :)
2012-07-24 15:42 <rhubner> nicoe: I tried to set context ... but didnt work
2012-07-24 15:42 <rhubner> nicoe: only date must be set in context?
2012-07-24 15:43 <nicoe> rhubner: you should have warned me about your vacation
2012-07-24 15:44 <nicoe> rhubner: when will you be back ?
2012-07-24 15:45 <rhubner> nicoe: my vacation is about education and work... I can dedicate the time to GSoC now, all day!
2012-07-24 15:47 <nicoe> rhubner: I don't understand when did your vacation started ?
2012-07-24 15:47 <rhubner> nicoe: I finished my master degree before the time
2012-07-24 15:48 <nicoe> rhubner: you're available to work full time on the project?
2012-07-24 15:48 <nicoe> ACTION can't believe he is having this discussion now
2012-07-24 15:48 <rhubner> nicoe: yes
2012-07-24 15:49 <nicoe> rhubner: good, then I hope I can expect a lot of progress in the next two weeks.
2012-07-24 15:49 <rhubner> nicoe: yes... of course
2012-07-24 15:52 <nicoe> rhubner: good
2012-07-24 15:56 <rhubner> nicoe: what exactly do I have to do to change the context and load other data?
2012-07-24 15:57 <rhubner> nicoe: I think iam "skating" on it now
2012-07-24 15:57 <nicoe> rhubner: first of all you should fix all the problems I reported
2012-07-24 15:57 <nicoe> rhubner: what do you mean by "skating" ?
2012-07-24 15:58 <rhubner> nicoe: wasting time...
2012-07-24 16:01 <nicoe> rhubner: to set the context you must play with rpc.CONTEXT
2012-07-24 16:01 <nicoe> rhubner: search for this string in the code
2012-07-24 16:03 <nicoe> rhubner: look after it in tryton/common/common.py
2012-07-24 16:03 <nicoe> rhubner: There is the definition of the RPCExecute call you're doing which enables you to send the context
2012-07-24 16:08 <rhubner> nicoe: ok... when I changed the context and call reload, the data will be change too?
2012-07-24 16:08 <Timitos> nicoe: rhubner: there is also another context. the one of the record: http://hg.tryton.org/tryton/file/cbf6282bd024/tryton/gui/window/view_form/model/record.py#l386
2012-07-24 16:08 <Timitos> i noticed that the _datetime value is not set in rpc.CONTEXT but in the context of the record
2012-07-24 16:09 <nicoe> Timitos: this is not the context of the record but of the group of record
2012-07-24 16:10 <Timitos> nicoe: but this was the place where i could find the _datetime value. not in rpc.CONTEXT
2012-07-24 16:10 <nicoe> rhubner: the screen.reload call should indeed reload the record with the correct context set
2012-07-24 16:11 <rhubner> good
2012-07-24 16:11 <nicoe> rhubner: do not forget also that once the record has been reloaded to a previous date, this record MUST become readonly
2012-07-24 16:12 <Timitos> nicoe: rhubner: i have another question about historization. shouldn´t the historization dive into the relations like the domain inversion?
2012-07-24 16:14 <rhubner> nicoe: haaa... that's what I would ask... i didnt find a visible method to mark the form as read-only. Is there any?
2012-07-24 16:15 <nicoe> rhubner: I don't know
2012-07-24 16:15 <rhubner> nicoe: so.. I'll investigate it
2012-07-24 16:16 <nicoe> Timitos: I think it should indeed
2012-07-24 16:17 <rhubner> nicoe: i'd like to talk about the problems in codereview now
2012-07-24 16:17 <Timitos> nicoe: i had to dive into this topic in the last days and found some problems with this. for the moment it is not working. but i do not have a completely working fix yet. just a little bit of it.
2012-07-24 16:18 <nicoe> rhubner: go ahead
2012-07-24 16:18 <rhubner> nicoe: you ask me about this line in timeline_widget.py: if self.screen.views_preload:
2012-07-24 16:19 <nicoe> rhubner: I meant go ahead and comment the codereview
2012-07-24 16:19 <rhubner> nicoe: I checked if this is true is to get information immediately after: info = self.screen.views_preload['form']
2012-07-24 16:22 <rhubner> nicoe: because there are times when the "self.screen.views_preload" is empty
2012-07-24 16:26 <nicoe> rhubner: indeed views_preload is not the correct way to get the form information
2012-07-24 16:27 <nicoe> rhubner: in screen.py there is code to add_view into a screen that's where you should get/set the information about the history
2012-07-24 16:28 <rhubner> ok .. i'll see it...
2012-07-24 16:29 <rhubner> nicoe: you said that the widget is not recreated again, but did you remove the comment the last line?: # self.screen.reload ()
2012-07-24 16:30 <nicoe> rhubner: of course
2012-07-24 16:30 <rhubner> nicoe: did you change anything else?
2012-07-24 16:31 <nicoe> rhubner: indeed because it did not work out of the box
2012-07-24 16:31 <rhubner> nicoe: in my tests, all methods are called again, including __ init__
2012-07-24 16:31 <nicoe> rhubner: what is your test?
2012-07-24 16:33 <rhubner> nicoe: I put a print in every methods and all are passed again after reloading
2012-07-24 16:33 <nicoe> rhubner: but how do you test it ?
2012-07-24 16:33 <nicoe> rhubner: on which model did you put _history=True ?
2012-07-24 16:36 <rhubner> nicoe: no no .. after changing a value on the scale, the reload is done. Then I send print a structure in __init__, but prints blank, because everything was rebuilt again.
2012-07-24 16:37 <rhubner> nicoe: how was your test to not recreate it all again?
2012-07-24 16:39 <nicoe> rhubner: I made party.party historizable and then I debugged your code in order to go through all the errors I had
2012-07-24 16:40 <nicoe> rhubner: Then I de-commented the reload line and voila ...
2012-07-24 16:42 <nicoe> rhubner: obviously I put print into different __init__ to trace the calls
2012-07-24 16:44 <rhubner> nicoe: why mine did different then...
2012-07-24 16:44 <rhubner> nicoe: I will fix everything after and test it again!
2012-07-24 16:44 <nicoe> I don't know that's why I ask you : how do you test?
2012-07-24 16:45 <nicoe> rhubner: What is the historizable model ?
2012-07-24 16:45 <nicoe> rhubner: how do you access it?
2012-07-24 16:45 <rhubner> nicoe: i have lunch now... i will be back in some minutes
2012-07-24 17:18 <rhubner> nicoe: ok...
2012-07-24 17:19 <rhubner> nicoe: I didnt understand your last two questions
2012-07-24 17:20 <nicoe> rhubner: What model in trytond did you use to test the timeline?
2012-07-24 17:20 <nicoe> rhubner: How in the client do you access the data ?
2012-07-24 17:21 <rhubner> nicoe: i am using party.address
2012-07-24 17:21 <rhubner> nicoe: I only used this until now
2012-07-24 17:21 <nicoe> rhubner: How do you access it?
2012-07-24 17:23 <rhubner> nicoe: on GUI?
2012-07-24 17:23 <nicoe> rhubner: yes
2012-07-24 17:23 <rhubner> nicoe: Party > Parties -> 2 cliks at one recorded
2012-07-24 17:25 <nicoe> rhubner: The problem comes from the fact that you're testing with party.address
2012-07-24 17:26 <rhubner> nicoe: but it was not to work?
2012-07-24 17:27 <nicoe> rhubner: Indeed it should also work
2012-07-24 17:27 <nicoe> rhubner: but in that case you're not taking the simplest exemple to start with because the party address is a view inside another model view
2012-07-24 17:28 <nicoe> rhubner: this is relation problem we were talking with Timitos last time
2012-07-24 17:28 <nicoe> rhubner: If I were you I would start with a simple example and then make it more complex
2012-07-24 17:29 <rhubner> nicoe: did you force the moder be historizable?
2012-07-24 17:30 <rhubner> model*
2012-07-24 17:32 <nicoe> rhubner: I don't understand
2012-07-24 17:33 <rhubner> nicoe: I understand now... I didnt put _history=True in modules
2012-07-24 17:34 <rhubner> nicoe: I used a model that it has a history... therefore i used party.address
2012-07-24 17:34 <rhubner> nicoe: did you understand?
2012-07-24 17:34 <rhubner> nicoe: I didnt put _history=True in NO modules
2012-07-24 17:34 <rhubner> *
2012-07-24 17:35 <nicoe> rhubner: Yep I understood
2012-07-24 17:37 <rhubner> nicoe: how did you made party.party historizable?
2012-07-24 17:38 <nicoe> rhubner: I put '_history = True' in the party.party definition in the party module
2012-07-24 17:41 <rhubner> nicoe: in party.py on class Party?
2012-07-24 17:46 <nicoe> rhubner: obviously
2012-07-24 17:48 <rhubner> nicoe: done... i'll continue the job now... thanks
2012-07-24 17:48 <nicoe> rhubner: you're welcome
2012-07-24 18:12 -!- scrapper(~scrapper@88.117.159.6) has left #tryton
2012-07-24 19:14 -!- mr_amit(~amit@1.22.99.143) has left #tryton
2012-07-24 19:20 -!- cristatus(~amit@1.22.99.143) has left #tryton
2012-07-24 19:48 <shomon> hello?
2012-07-24 19:48 <shomon> I just installed tryton according to the gnuhealth install pages, but it's come out with no modules.. anyone else had that?
2012-07-24 20:30 <smarro> shomon: i think it's better if you ask gnuhealth questions in the #gnuhealth channel...
2012-07-24 21:04 <shomon> ok smarro sorry.. I guess the question is.. if libraries installed somewhere other than where youwanted them, how do you move them over?
2012-07-24 21:04 <shomon> can I just copy them?
2012-07-24 21:04 <shomon> but I'll ask it in a more gnuhealthy way over there too
2012-07-24 21:07 <rhubner> shomom: the modules dont show?
2012-07-24 21:07 <rhubner> shomon: the modules dont show?
2012-07-24 21:09 <rhubner> shomon: you have to install modules and after update de database
2012-07-24 21:09 <smarro> rhubner: shomon has incompatible versions of trytond and gnuhealth
2012-07-24 21:10 <smarro> rhubner: i'm chatting with him in #gnuhealth
2012-07-24 21:10 <shomon> :)
2012-07-24 21:11 <rhubner> haaa ... ow sorry!
2012-07-24 21:11 <smarro> rhubner: no problem, :)
2012-07-24 21:11 <shomon> thanks anyway rhubner
2012-07-24 21:50 -!- rhubner(~rhubner@189.114.255.204) has left #tryton
2012-07-24 23:06 -!- RickorDD(~RickorDD@p579D27E8.dip.t-dialin.net) has left #tryton

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!