IRC logs of #tryton for Tuesday, 2012-07-24 #tryton log beginning Tue Jul 24 00:00:01 CEST 2012
sharoonthomascedk: ping08:47
cedksharoonthomas: pong09:17
sharoonthomascedk: just wanted to discuss how time / date time is stored in tryton09:31
cedksharoonthomas: as time and datetime09:32
sharoonthomascedk: not that :) its about the tz and conversion09:32
sharoonthomascedk: from what i see we store localized time based on the system local time09:34
sharoonthomascedk: i think it is wrong because it is not always possible to convert for a local timezone time to a different time09:35
sharoonthomascedk: i think we should store timezone naive utc09:35
cedksharoonthomas: why should it not always possible to convert?09:38
sharoonthomascedk: found it :)
cedksharoonthomas: that's something else09:47
sharoonthomascedk: the issue will be there when the timezone is dst09:48
cedksharoonthomas: it is not about convertion09:49
sharoonthomascedk: rather if the timezone of the machine tryton is installed has end-of-daylight-savings-time transition09:49
cedksharoonthomas: "if you perform date arithmetic "09:50
sharoonthomascedk: don't we do arithmetic when the user has a preferred timezone ?09:50
cedksharoonthomas: no09:51
sharoonthomascedk: so how do we use ?09:52
cedksharoonthomas: without arithmetic09:53
sharoonthomascedk: can you explain ? i think i missed it then09:53
cedksharoonthomas: convertion is not arithmetic09:56
sharoonthomascedk: where is the conversion/localisation to the user's timezone done ?09:56
cedksharoonthomas: in the client09:56
sharoonthomascedk: and the client knows the server's timezone ?09:57
cedksharoonthomas: yes09:58
sharoonthomascedk: 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 exist10:00
sharoonthomascedk: the problem i expect to reproduce is:10:03
sharoonthomas>>> datetime(2012, 10, 27, 1, 30, tzinfo=eastern).astimezone(pytz.utc)10:03
sharoonthomasdatetime.datetime(2012, 10, 27, 6, 30, tzinfo=<UTC>)10:03
sharoonthomas>>> datetime(2012, 10, 27, 6, 30, tzinfo=pytz.utc).astimezone(eastern)10:03
sharoonthomasdatetime.datetime(2012, 10, 27, 2, 30, tzinfo=<DstTzInfo 'US/Eastern' EDT-1 day, 20:00:00 DST>)10:03
cedksharoonthomas: I don't see any problem10:04
cedksharoonthomas: for me, it looks like there are 2 representation of the datetime in tz eastern10:07
sharoonthomascedk: did u read the last part of the pytz documentation10:07
sharoonthomascedk: the problem is that in sometime zone (like US/Eastern) the same time can appear twice10:08
sharoonthomascedk: for example, datetime(2002, 10, 27, 1, 30, 00, tzinfo=eastern) can occur twice10:08
sharoonthomascedk: and in tryton we would have stored timezone naive date time which is datetime(2002, 10, 27, 1, 30, 00)10:09
sharoonthomascedk: from that stored date time, there is no way to distinguish if it was the first 1:30 AM or the second 1:30 AM10:09
cedksharoonthomas: yes that's what happen when you use a non-increasing tz10:09
cedksharoonthomas: storing the tz doesn't help10:10
sharoonthomascedk: which also means that if you localize the time (using any mechanism) to a timezone like UTC/IST there is a 50% chance its off10:10
sharoonthomascedk: the solution is we should store UTC (storing tz is NOT a solution)10:11
sharoonthomascedk: 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 safe10:12
cedksharoonthomas: set UTC in your configuration10:12
sharoonthomascedk: thats the workaround, not a solution10:13
sharoonthomascedk: and we already do that10:13
cedksharoonthomas: what is your solution ?10:14
sharoonthomascedk: here is another article which explains and strongly suggests internally only UTC date times (without timezone) must be handled10:14
sharoonthomascedk: datetime.utcnow()10:15
cedksharoonthomas: that's what we do except: the standard tz is configurable and we don't warn user for ambigous datetime10:27
sharoonthomascedk: exactly, so if trytond is on a machine in UTC, there is no problem10:28
sharoonthomascedk: i think we should issue an advisory note on installation page for current versions, but should we not fix this in a future release ?10:28
cedksharoonthomas: no10:28
sharoonthomascedk: what about nest ?10:29
sharoonthomascedk: we cannot expect a nest user to change his timezone to UTC10:29
cedksharoonthomas: when you use with only 1 timezeone there are no problem and it is better to get local datetime10:29
cedksharoonthomas: for neso we don't care10:29
sharoonthomascedk: for me, i think this is something the application should take care of, and i think its wrong10:30
sharoonthomascedk: i already have a few customers on US/Eastern who now have users in Brazil and shipping times already look weird!10:31
cedksharoonthomas: use UTC10:33
sharoonthomascedk: yes and also convert dates all across the system (in every single field for it to make sense)10:34
sharoonthomascedk: s/system/database10:34
yangoonsharoonthomas: as you say, UTC for the server is the way to go10:59
yangoonsimply because it is the only timezone which won't suffer from any changes or corrections10:59
sharoonthomasyangoon: ok, so you think it should go into trytond ?11:00
yangoonsharoonthomas: there is another problem11:01
yangoonsharoonthomas: the timezone, the company lives in11:01
sharoonthomasyangoon: is that important ? may be for the reports ?11:02
yangoonwe creeated for our use a module, which handles conversion of server timezone to company timezone and user timezone to company timezone11:02
yangoonsharoonthomas: think for contracts11:02
yangoonthey must have a fixed date for the legal beginning etc.11:02
yangoonthink for cron tasks, that should be run at defined dates for the *company*11:03
yangoonfinally the legal entity is the company, it is not important, where the user works11:03
sharoonthomasyangoon: but can't we use the timezone of the cron user ?11:04
yangoonsharoonthomas: I think the cron user works with the timezone of the server11:05
sharoonthomasyangoon: 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 mentioned11:05
yangoonwhich doesn't need to be that of the company11:05
sharoonthomasyangoon: agree11:05
-!- smoldersan_(~smoldersa@ has left #tryton12:04
-!- kpouget( has left #tryton15:29
rhubnerHi nicoe15:37
nicoerhubner: hello15:38
rhubnernicoe: I'm on vacation now ... I will finish everything before the deadline! :)15:41
rhubnernicoe: I tried to set context ... but didnt work15:42
rhubnernicoe: only date must be set in context?15:42
nicoerhubner: you should have warned me about your vacation15:43
nicoerhubner: when will you be back ?15:44
rhubnernicoe: my vacation is about education and work... I can dedicate the time to GSoC now, all day!15:45
nicoerhubner: I don't understand when did your vacation started ?15:47
rhubnernicoe: I finished my master degree before the time15:47
nicoerhubner: you're available to work full time on the project?15:48
nicoeACTION can't believe he is having this discussion now15:48
rhubnernicoe: yes15:48
nicoerhubner: good, then I hope I can expect a lot of progress in the next two weeks.15:49
rhubnernicoe: yes... of course15:49
nicoerhubner: good15:52
rhubnernicoe: what exactly do I have to do to change the context and load other data?15:56
rhubnernicoe: I think iam "skating" on it now15:57
nicoerhubner: first of all you should fix all the problems I reported15:57
nicoerhubner: what do you mean by "skating" ?15:57
rhubnernicoe: wasting time...15:58
nicoerhubner: to set the context you must play with rpc.CONTEXT16:01
nicoerhubner: search for this string in the code16:01
nicoerhubner: look after it in tryton/common/common.py16:03
nicoerhubner: There is the definition of the RPCExecute call you're doing which enables you to send the context16:03
rhubnernicoe: ok... when I changed the context and call reload, the data will be change too?16:08
Timitosnicoe: rhubner: there is also another context. the one of the record:
Timitosi noticed that the _datetime value is not set in rpc.CONTEXT but in the context of the record16:08
nicoeTimitos: this is not the context of the record but of the group of record16:09
Timitosnicoe: but this was the place where i could find the _datetime value. not in rpc.CONTEXT16:10
nicoerhubner: the screen.reload call should indeed reload the record with the correct context set16:10
nicoerhubner: do not forget also that once the record has been reloaded to a previous date, this record MUST become readonly16:11
Timitosnicoe: rhubner: i have another question about historization. shouldn´t the historization dive into the relations like the domain inversion?16:12
rhubnernicoe: haaa... that's what I would ask... i didnt find a visible method to mark the form as read-only. Is there any?16:14
nicoerhubner: I don't know16:15
rhubnernicoe: so.. I'll investigate it16:15
nicoeTimitos: I think it should indeed16:16
rhubnernicoe: i'd like to talk about the problems in codereview now16:17
Timitosnicoe: 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.16:17
nicoerhubner: go ahead16:18
rhubnernicoe: you ask me about this line in if self.screen.views_preload:16:18
nicoerhubner: I meant go ahead and comment the codereview16:19
rhubnernicoe: I checked if this is true is to get information immediately after: info = self.screen.views_preload['form']16:19
rhubnernicoe: because there are times when the "self.screen.views_preload" is empty16:22
nicoerhubner: indeed views_preload is not the correct way to get the form information16:26
nicoerhubner: in there is code to add_view into a screen that's where you should get/set the information about the history16:27
rhubnerok .. i'll see it...16:28
rhubnernicoe: you said that the widget is not recreated again, but did you remove the comment the last line?: # self.screen.reload ()16:29
nicoerhubner: of course16:30
rhubnernicoe: did you change anything else?16:30
nicoerhubner: indeed because it did not work out of the box16:31
rhubnernicoe: in my tests, all methods are called again, including __ init__16:31
nicoerhubner: what is your test?16:31
rhubnernicoe: I put a print in every methods and all are passed again after reloading16:33
nicoerhubner: but how do you test it ?16:33
nicoerhubner: on which model did you put _history=True ?16:33
rhubnernicoe: 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.16:36
rhubnernicoe: how was your test to not recreate it all again?16:37
nicoerhubner: I made historizable and then I debugged your code in order to go through all the errors I had16:39
nicoerhubner: Then I de-commented the reload line and voila ...16:40
nicoerhubner: obviously I put print into different __init__ to trace the calls16:42
rhubnernicoe: why mine did different then...16:44
rhubnernicoe: I will fix everything after and test it again!16:44
nicoeI don't know that's why I ask you : how do you test?16:44
nicoerhubner: What is the historizable model ?16:45
nicoerhubner: how do you access it?16:45
rhubnernicoe: i have lunch now... i will be back in some minutes16:45
rhubnernicoe: ok...17:18
rhubnernicoe: I didnt understand your last two questions17:19
nicoerhubner: What model in trytond did you use to test the timeline?17:20
nicoerhubner: How in the client do you access the data ?17:20
rhubnernicoe: i am using party.address17:21
rhubnernicoe: I only used this until now17:21
nicoerhubner: How do you access it?17:21
rhubnernicoe: on GUI?17:23
nicoerhubner: yes17:23
rhubnernicoe: Party > Parties -> 2 cliks at one recorded17:23
nicoerhubner: The problem comes from the fact that you're testing with party.address17:25
rhubnernicoe: but it was not to work?17:26
nicoerhubner: Indeed it should also work17:27
nicoerhubner: but in that case you're not taking the simplest exemple to start with because the party address is a view inside another model view17:27
nicoerhubner: this is relation problem we were talking with Timitos last time17:28
nicoerhubner: If I were you I would start with a simple example and then make it more complex17:28
rhubnernicoe: did you force the moder be historizable?17:29
nicoerhubner: I don't understand17:32
rhubnernicoe: I understand now... I didnt put _history=True in modules17:33
rhubnernicoe: I used a model that it has a history... therefore i used party.address17:34
rhubnernicoe: did you understand?17:34
rhubnernicoe: I didnt put _history=True in NO modules17:34
nicoerhubner: Yep I understood17:35
rhubnernicoe: how did you made historizable?17:37
nicoerhubner: I put '_history = True' in the definition in the party module17:38
rhubnernicoe: in on class Party?17:41
nicoerhubner: obviously17:46
rhubnernicoe: done... i'll continue the job now... thanks17:48
nicoerhubner: you're welcome17:48
-!- scrapper(~scrapper@ has left #tryton18:12
-!- mr_amit(~amit@ has left #tryton19:14
-!- cristatus(~amit@ has left #tryton19:20
shomonI just installed tryton according to the gnuhealth install pages, but it's come out with no modules.. anyone else had that?19:48
smarroshomon: i think it's better if you ask gnuhealth questions in the #gnuhealth channel...20:30
shomonok smarro sorry.. I guess the question is.. if libraries installed somewhere other than where youwanted them, how do you move them over?21:04
shomoncan I just copy them?21:04
shomonbut I'll ask it in a more gnuhealthy way over there too21:04
rhubnershomom: the modules dont show?21:07
rhubnershomon: the modules dont show?21:07
rhubnershomon: you have to install modules and after update de database21:09
smarrorhubner: shomon has incompatible versions of trytond and gnuhealth21:09
smarrorhubner: i'm chatting with him in #gnuhealth21:10
rhubnerhaaa ... ow sorry!21:11
smarrorhubner: no problem, :)21:11
shomonthanks anyway rhubner21:11
-!- rhubner(~rhubner@ has left #tryton21:50
-!- RickorDD( has left #tryton23:06

Generated by 2.11.0 by Marius Gedminas - find it at!