profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/alexey-pelykh/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

alexey-pelykh/webp-android-backport 521

WebP format support for Android <4.0

alexey-pelykh/glTF-Blender-IO 2

Blender glTF 2.0 importer and exporter

alexey-pelykh/argo 0

Argo Workflows: Get stuff done with Kubernetes.

alexey-pelykh/DefinitelyTyped 0

The repository for high quality TypeScript type definitions.

alexey-pelykh/filament 0

Filament is a real-time physically based rendering engine for Android, iOS, Windows, Linux, macOS and WASM/WebGL

alexey-pelykh/gltflib 0

Library for parsing, creating, and converting glTF 2.0 files in Python 3.6+.

alexey-pelykh/HoudiniGLTF 0

Houdini's glTF integration

alexey-pelykh/material-ui 0

React components that implement Google's Material Design.

alexey-pelykh/node 0

Node.js JavaScript runtime :sparkles::turtle::rocket::sparkles:

alexey-pelykh/Pelykh.Common 0

Common .NET libraries

Pull request review commentOCA/currency

[12.0][IMP] currency_rate_update_oxr: optional end-of-day exchange rates

 def _get_supported_currencies(self):     @api.multi     def _obtain_rates(self, base_currency, currencies, date_from, date_to):         self.ensure_one()+        eod_rates = self.company_id.openexchangerates_eod_rates         if self.service != 'OXR':             return super()._obtain_rates(base_currency, currencies, date_from,                                          date_to)  # pragma: no cover          content = defaultdict(dict) -        date = date_from-        while date <= date_to:+        date = date_from - timedelta(days=1) if eod_rates else date_from+        while date <= (date_to - timedelta(days=1) if eod_rates else date_to):

just alter date_to?

pankk

comment created time in 18 hours

Pull request review commentOCA/currency

[12.0][IMP] currency_rate_update_oxr: optional end-of-day exchange rates

 class ResCompany(models.Model):     openexchangerates_app_id = fields.Char(         string='OpenExchangeRates.org App ID',     )+    openexchangerates_eod_rates = fields.Boolean(

I would suggest adding this option to parent module as use_last_end_of_day_rates or similar, since in theory not only OXR could have such option (to reduce number of fields)

pankk

comment created time in 18 hours

PullRequestReviewEvent
PullRequestReviewEvent

pull request commentOCA/hr

[FIX] hr_employee_service_contract: Set fields as not prefetched

/ocabot merge patch

etobella

comment created time in a day

PullRequestReviewEvent

pull request commentOCA/timesheet

[13.0] [MIG] sale_timesheet_line_exclude

/ocabot merge nobump

Du-ma

comment created time in 9 days

PullRequestReviewEvent

Pull request review commentOCA/currency

[14.0][MIG] currency_rate_inverted: Migration to 14.0

  {     "name": "Currency Rate Inverted",-    "version": "13.0.1.0.1",+    "version": "14.0.1.0.0",

This version change should be done as a separate commit. See https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-14.0

tupaq

comment created time in 15 days

PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent

delete branch corporatehub/mis-builder

delete branch : 12.0-imp-mis_builder-remove_size_limit

delete time in 21 days

PullRequestReviewEvent

issue commentgoogle/filament

Why matc emits binary-different materials from same source?

(1.9.15) matc -p mobile -a opengl -o test.matc test.mat ; sha256sum test.matc produces

3863e48c1adbde465d885e532855ac4400a55bd1f776e5087220ba7dba585084  test.matc
a8a4b70702ebc56d33e0524a92a86ad4579d14134228d353ccfbe139f5b8cccb  test.matc
...

during multiple runs, but 1.12.1 matc seems to produce consistent results. I'd guess something has been fixed after 1.9.15?

alexey-pelykh

comment created time in 23 days

PullRequestReviewEvent

pull request commentOCA/bank-statement-import

[FIX] account_bank_statement_import_online_paypal: timezone handling

ah, and there I see the problem: In https://github.com/OCA/bank-statement-import/blob/12.0/account_bank_statement_import_online/tests/online_bank_statement_provider_dummy.py#L60 you don't convert to the timezone in question, you just declare the time is in this timezone. What we need here is tz.localize(date).astimezone(pytz.utc).replace(tzinfo=None), see http://pytz.sourceforge.net/#localized-times-and-date-arithmetic - you want to generate the interval in the target timezone (what you put in the context), and then pull transactions with provider.tz.

Awesome finding! So that means, that tz-related tests would be incorrect due to that.

Why do we have all the checks for tzinfo in the code anyways? Internally, Odoo only ever uses naive datetimes expressing UTC times.

Depends on which checks do you refer to, e.g. arguments to pull method - just in case I ever planned to call it from somewhere else. Defensive programming, nothing more.

hbrunn

comment created time in 24 days

pull request commentOCA/bank-statement-import

[FIX] account_bank_statement_import_online_paypal: timezone handling

as a user you don't have control which intervals are requested exactly, this complicates things.

There's a wizard that allows to pull specific period of time manually, e.g. to pull old data after installing the module. Surely, it's not the approach anyone would want to use regularly.

How can you as a user now set the exact interval?

Please describe in details why anyone would want that? Apart for occasional manual pull described above, online bank statements are supposed to be plug-and-play, configure once and forget.

It's part of the problem that whatever you fill in for next_date in the UI will be converted to UTC internally,

That field was never intended to be changed manually. In my deployments I never ever had to change it, or had any reason to. Thus again, please describe what exactly you're trying to accomplish by changing that field manually. It's not even exposed to normal user under normal circumstances.

So yes, case 1 we don't want, case 2 we want, and case 3 then yes, it's a choice not to set a timezone on the provider and then you get UTC, so the 19th CEST is split over two days/statements when the provider is UTC.

Awesome, it would be great if you'd take a look as well on test cases that covert self.tz usage in main module, maybe you'll uncover something as well. I'll take a look at those as well tomorrow just to ensure I didn't miss anything. Until today I was under impression that case 2 is working, because I've even covered that with tests.

hbrunn

comment created time in 24 days

pull request commentOCA/bank-statement-import

[FIX] account_bank_statement_import_online_paypal: timezone handling

Okay, I got your point, yet it's slightly other way round with same result.

Case 1:

User having CEST timezone makes a pull '2021-09-19 02:00:00'-'2021-09-20 02:00:00' via UI from a "daily" provider with CEST timezone. That request produces 1 statement with 2021-09-19 date containing '2021-09-19 00:00:00 CEST' through '2021-09-20 00:00:00 CEST'.

That's a strict no, super confusing.

Case 2:

User having CEST timezone makes a pull '2021-09-19 00:00:00'-'2021-09-20 00:00:00' via UI from a "daily" provider with CEST timezone. That request produces 1 statement with 2021-09-19 date containing '2021-09-19 00:00:00 CEST' through '2021-09-20 00:00:00 CEST'.

That's a yes, I'd expect that to happen as well.

Case 3:

User having CEST timezone makes a pull '2021-09-19 00:00:00'-'2021-09-20 00:00:00' via UI from a "daily" provider without timezone. That request produces 2 statements with 2021-09-18 and 2021-09-19 dates containing '2021-09-19 00:00:00 CEST' through '2021-09-19 02:00:00 CEST' in one and '2021-09-19 02:00:00 CEST' through '2021-09-20 00:00:00 CEST' in second. That's statement date being in UTC as well as transaction dates being in UTC.

That's a yes, I'd expect that to happen as well.

If we're on the same page, for you case 2 fails and you get two statements? This may sound silly, yet I'd prefer to iron out this timezone thing once and for all.

hbrunn

comment created time in 24 days

pull request commentOCA/bank-statement-import

[FIX] account_bank_statement_import_online_paypal: timezone handling

the transactions from '2021-09-19 02:00:00 CEST' to '2021-09-20 02:00:00 CEST'

And you'd expect that to produce two statements (with provider tz being set to CEST)?

hbrunn

comment created time in 24 days

pull request commentOCA/bank-statement-import

[FIX] account_bank_statement_import_online_paypal: timezone handling

Statements contain the UTC interval, not the localized interval if provider.tz is set

Interval as "statement date is being in UTC"? That's being "since" date?

hbrunn

comment created time in 24 days

pull request commentOCA/bank-statement-import

[FIX] account_bank_statement_import_online_paypal: timezone handling

If I got that correctly, issue is: "When provider's Timezone is set to CEST, function that computes statement date from transaction produces wrong date (that is still UTC-ish)" - right?

hbrunn

comment created time in 24 days

pull request commentOCA/bank-statement-import

[FIX] account_bank_statement_import_online_paypal: timezone handling

Also, next_run is hourly by default, why would we want any TZ there?

hbrunn

comment created time in 24 days

pull request commentOCA/bank-statement-import

[FIX] account_bank_statement_import_online_paypal: timezone handling

What I propose here is indeed only a workaround for the base module handling timezones incorrectly, but we can't rewrite all of this in v12 now.

It shouldn't be a rewrite, at least in my mind. By default everything was UTC and that case is handled well, the case with non-UTC setting (that PR specifically) must have something missing in it, so I don't think it would be a massive rewrite. In any case, we can start with a test case in base module that exposes the issue.

I just realize for people who already have wrong intervals imported, this change is indeed a problem

Shouldn't be that dramatic, since data duplication won't occur. But re-pulling data may cause issues, true. But major version bump would do?

But that can be fixed with a migration script that sets next_run to the force localized version of the date,

I'm against anything forced. Ideally, there should be a setting that allows TZ to be set, if user wants to, that would do the amendment to the behaviour.

hbrunn

comment created time in 24 days

pull request commentOCA/bank-statement-import

[FIX] account_bank_statement_import_online_paypal: timezone handling

Do you think it's correct behavior that the statements show transactions from the UTC period of its date instead of the localized one?

I think that the correct way is to let user decide which TZ should be used for statements. That PR that introduced TZ probably didn't cover it fully, yet it was supposed so, IIRC.

Setting TZ to CEST should've done the trick, while keeping it a UTC should've kept things unchanged. So if anything of that is false, I would consider it a bug of base module to be honest vs bug of this exact provider.

I have some companies that do UTC statements due to them being international, others like local timezones, yet since I've never heard of this issue before - I assume nobody checked or cared.

hbrunn

comment created time in 24 days

pull request commentOCA/bank-statement-import

[FIX] account_bank_statement_import_online_paypal: timezone handling

Ah, true, misunderstood you. Well, regardless, it should be something handled by settings since it's quite a breaking change - and not a fix exactly.

hbrunn

comment created time in 24 days

pull request commentOCA/bank-statement-import

[FIX] account_bank_statement_import_online_paypal: timezone handling

But at least now I understand why you want minutes to be erased, since 00:42 would screw up the filtering. But 00:42 shouldn't be there in the first place.

hbrunn

comment created time in 24 days

pull request commentOCA/bank-statement-import

[FIX] account_bank_statement_import_online_paypal: timezone handling

well, but it doesn't. I've set the timezone there, and as you see from my debug description above, you will end up with wrong balances per day, because here in my case you'll compare something like 2021-09-18 22:42:00 (00:42 CEST) with 2021-09-19 00:00:00, and throw out the transaction (it will then show up on the statement before).

Then it sounds like a bug, especially 00:42 CEST, somewhere in code related to datetime conversion, likely in base module itself. And it would be great to start with a test case that exposes this 00:42 shift first.

IIRC, I've seen such 00:42 shift sometime ago and it was due to which function was used to make timezone conversion.

If we could redesign all of the code, it would simplify stuff a lot to use the date type in the base plugin, and only do timezone conversions/datetime stuff if the provider handles UTC internally like paypal.

That would lead to a lot of copypaste between modules, most of them are timezone and datetime aware, so making base module being date-only is not great, imho. This was considered when initial development held place.

hbrunn

comment created time in 24 days

pull request commentOCA/bank-statement-import

[FIX] account_bank_statement_import_online_paypal: timezone handling

we set the pulling to daily

pulling is done hourly by default, setting of daily/weekly/monthly changes only how often separate statements are created. E.g. I'm using weekly statements in 99% cases.

the statement for the 19th doesn't contain all transactions from 2021-09-19 00:00:00 (CEST) to 2021-09-20 00:00:00 (CEST), it contains the transactions from 2021-09-19 02:00:00 (CEST) to 2021-09-20 02:00:00 (CEST)

yes, which is intended behaviour unless this setting is changed. Setting that to CEST should accomplish the result that you're seeking, if memory serves me.

hbrunn

comment created time in 24 days

Pull request review commentOCA/bank-statement-import

[FIX] account_bank_statement_import_online_paypal: timezone handling

 def _obtain_statement_data(self, date_since, date_until):             'balance_end_real': balance_end,         } +    @api.multi+    def _get_statement_date_step(self):+        delta = super()._get_statement_date_step()+        if self.service == 'paypal':

yes, that's obvious, yet still - it seems to me that this code part effectively changes nothing.

hbrunn

comment created time in 24 days