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

[yoyo2k]

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]

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

[feketemihai]

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

[filsys]

Serverul ignora timezone. Ramane in UTC.

[yoyo2k]

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]

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" [email protected] 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]

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]

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]

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]

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]

Uite şi issue de la ei specific statului de plată:
odoo/odoo#3681

[bodi000]

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

[yoyo2k]

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.