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/!