Aleksandr Razumov comments

Results 142 comments of


                                            Aleksandr Razumov

FromID same for both parties in one to one chat

For now you can use [Client.Self](https://pkg.go.dev/github.com/gotd/td/telegram#Client.Self) method to access current UserID and cache it. Initially @xjem proposed to do it implicitly (cache it on first call and set FromID), but...

client: improve FLOOD_WAIT handling

Related: #271

Accept interface instead of *zap.Logger

Yes, this can be achieved in #15 Currently I can't come with a way of abstracting out zap logging without losing performance or usability. Can you please provide examples of...

Accept interface instead of *zap.Logger

```go // L defined logger interface used everywhere in the package type L interface { Logf(format string, args ...interface{}) } ``` So there are no way to use subloggers, structured...

Accept interface instead of *zap.Logger

I need statically typed structured logger with good performance, if someone will come up with zap-like interface for abstract logger I'm ok with it.

Accept interface instead of *zap.Logger

I'll return to this near 1.0 release, probably I'll extract abstract logger to separate package under gotd org. I've seen lots of bad approaches to this problem and just don't...

ci: run tests in Chrome to test WASM platform support

We can use chromedp here, pretty trivial

Consider server timezone for Datetimes with Zone

Personally I prefer always using `time.Time` directly, client and server should handle timezones automatically for DateTime, DateTime64. Internally (on the wire) it is always UTC, TZ is used only for:...

Insert into ClickHouse table with DateTime64 data type using character type time, the value is 8 hours more than the original value

What time do you expect when specifying `2022-07-20 17:42:48` on insert? * Server time zone * Client local time zone * UTC

`SELECT toString(number) FROM numbers(500000000)` is slow

The reason is strings are encoded as length-value, so for each row we first decode length and then read value. That leads to much higher overhead compared to UInt64, because...