search

feketemihai / l10n-romania

Odoo/OpenERP Romania Localization
GNU Affero General Public License v3.0
5 stars 13 forks source link

date în UTC (baza de date) și timezone-ul utilizatorului #65

Open yoyo2k opened 9 years ago

yoyo2k commented 9 years ago

o ciudățenie... (bug vechi? de pe vremea 6.1 și cam afectează tot hr-ul - attendance/timesheets/payroll și cam tot ce folosește field.Datetime/calendar) când introduci o cerere de concediu, în baza de date se salvează date_from & date_to în format UTC, dar tu introduci cu timezone-ul tău (+2h pt bucurești). exemplu concret: introduc e cerere de 2h la începutul programului de lucru (8:00-10:00 și programul de lucru 08-16). partea nasoală se întâmplă când e cererea de la 00:00, îți calculează 2 zile de concediu că în baza de date apare ca ziua precedentă 22:00.

aici m-am blocat la salarizare.

feketemihai commented 9 years ago

Aici poti calcula cu pytz din utc in timezone utilizator asociat angajatului daca are sau userul care e pus in timesheet...attendance...

feketemihai commented 9 years ago

Sau serverul pe bucharest si cu fields.datetime...

filsys commented 9 years ago

Serverul ignora timezone. Ramane in UTC.

yoyo2k commented 9 years ago

Corect @filsys. Odoo ia teoretic câmpurile date şi datetime şi le transformă în UTC. Aici intervine partea tâmpită. Să zicem că-ţi pui concediu de la începutul lunii viitoare. Când o să se facă ştatul o să apară o zi de concediu în luna curentă. Asta pentru că în db n-o să scrie 2015-03-01 00:00:00 ci 2015-02-28 22:00:00.

Am găsit un pull la odoo, dar linkul e pe comp, care teoretic ar rezolva problema. O s-o testez mâine.

Oricum, e o problemă serioasă care afectează multe părţi ale modulelor de hr care fac de ex căutări direct pe resultset cu filtre pe data fără să ia în considerare tz.

bodi000 commented 9 years ago

E din pacate o problema veche de cel putin 3ani.. credeam ca a fost rezolvata. Uita-te totusi in project sau mrp nu mai stiu unde au fost niste incercari de rezolvare.

O idee (netestata) ar fi sa stochezi si tz si sa se faca conversia cand e necesar. Dar pt exemplul nu stiu daca tine. E o problema si pt firme care lucreaza pe mai multe tz.

Sunt multe discutii pe launchpad. On 17 Feb 2015 18:29, "filsys" notifications@github.com wrote:

Serverul ignora timezone. Ramane in UTC.

— Reply to this email directly or view it on GitHub https://github.com/odoo-romania/l10n-romania/issues/65#issuecomment-74710747 .

filsys commented 9 years ago

In hr sunt totusi putine tranzactii. Iar cele de concediu pot fi evitate in RO. E vorba de doar 2 ore. Mai problematic este pe pontajele sign_id/out pe schimbul 2 si 3. Insa in stocuri pot fi mii de tranzactii in perioada de interferenta (00:00 - 01:59). In B.D. vor fi in ziua anterioara. Mai mult, contabilitatea pentru ele este generata in ziua anterioara. Pentru data de 01.ale lunii, toate receptiile procesate intre orele 00:01 si 01:59 vor fi in contabilitatea lunii anteriaore. Problema se mosteneste in rapoarte.

feketemihai commented 9 years ago

Da dar in noul api fields ai la datetime context_timestamp care iti ia direct in timezone user...e adevarat ca trebuie rescrise mai toate functiile ce iti dau interval ca sa fie corect...in cel vechi luam direct orele 10 zi 4 pentru calcul

filsys commented 9 years ago

E mai usor in noul api, dar tot trebuie rescrise functiile. Si avand in vedere ca impactul este mai ales pe functiile din modulele standard (nu in localizari), cred ca se incadreaza in categoria bug major de core/framework. Discutia asta se poarta de multa vreme. Dar cei de la OpenERP S.A. sunt ocupati cu schimbarea de licentiere: AGPL sa te oblige sa le dai codul, LGPL sa-l ia si sa-l valorifice fara restrictii.

yoyo2k commented 9 years ago

Ideea e bună să ai în db un standard, problema e în aplicaţiile care o folosesc, ele ar trebui să facă transformările.

yoyo2k commented 9 years ago

Uite şi issue de la ei specific statului de plată: https://github.com/odoo/odoo/issues/3681

bodi000 commented 9 years ago

uitati-va daca vreti si in odoo/odoo#5378 si odoo/odoo#5379. dar eu cred ca problema e rezolvata numai pe jumatate...

yoyo2k commented 9 years ago

Cred că am găsit solutia pt stat. sunt 3 tabele/modele hr_holidays, resource_calendar şi resource_calendar_leaves. în holidays se tin datele de început şi sfârsit in format utc ca să nu fie probleme la afișare (decalajul din cauza fusului orar), calendar e defapt programul de lucru care e independent de fus adică nu conteaza ca-s in america sau românia, tot la 8 încep lucru si calendar_leaves în care intră concediile aprobate şi sunt legate de angajati deci De fusul lor orar (până acum nu erau legate). Rezolvarea este rescrierea a 2 functii una din hr_holidays care crează calendar_leaves la aprobare şi din hr_payslip pt calcularea zilelor şi rezolvă şi folosirea unei functii depricated. Pt pontaj cred că s-ar putea aplica aceeași soluție.