[Feature Request] Get user timezone offset

[itsMoji]

Hi, It would be very useful if we could access the user's client timezone offset, maybe as a new field in the from object

"from":{
    "id": 0,
    "is_bot":false,
    "first_name":"",
    "username":"",
    "language_code":"en",
    "timezone_offset": 10800
}

[WaffleLapkin]

I think that it's expected that timezone offset is either inferred from language_code or explicitly asked from the user (maybe even both).

[nmlorg]

I think that it's expected that timezone offset is either inferred from language_code or explicitly asked from the user (maybe even both).

The user's country code used to be included in language_code, but some time between 2018-09-29 and 2019-06-03, either Telegram clients stopped sending the full locale code or Telegram began stripping the country code, so language_code is literally just a language code.

[ggsupr]

Even if Telegram sent user's country to the bot, it wouldn't be possible to determine the timezone, cause there are countries with multiple timezones.
The correct way to get the user's timezones is by asking them their location (a keyboard button with a request_location field for example).
I think that if Telegram automatically sent user timezones/IP address/locations to bots that would be seen as a location leak.

[itsMoji]

@ggsupr Yes, I agree it can reveal a general location, but asking the user's location isn't a good idea since it sends the exact location, and many users won't accept this.
If Telegram thinks timezone offset is a privacy risk, a better idea would be a new markdown to show the time and date in their timezone.
For example (in HTML markdown):
<date format="Y/m/d - H:i:s">1639044006</date>

[nmlorg]

The correct way to get the user's timezones is by asking them their location (a keyboard button with a request_location field for example).

Exact location is a little tricky:  Seattle, WA, US uses the time zone for Los Angeles, CA, US (America/Los_Angeles), but a user in Seattle is physically closest to the center of the time zone for Vancouver, BC, CA (America/Vancouver). In fact, Seattle is closer to 11 time zone centers than to America/Los_Angeles' center, so you'd need to use some huge data set or something live like Google Maps Time Zone API.

Even just current offset is problematic:  I use time zones to display the start/end times of future events, so when an event is coming up soon enough to warrant planning for, but with a daylight saving switchover between then and now, I would at best cause some irritation a couple times a year.

The only good answer I have found is to explicitly ask users, and knowing their country code was a useful starting point (but now I explicitly prompt for it). For what it's worth, in my zone.tab, 31 countries have multiple time zones but 216 have exactly one.

(Also for what it's worth, I would be happy to see a request_timezone added to KeyboardButton.)

[itsMoji]

@levlam Any thoughts on this?

[manzanit0]

Just a thought, but a feature like this would make the app less private: you would be able to pinpoint specific users to specific timezones, meaning you potentially locate them in specific parts of the globe.

[Cynical-Optimist]

Just a thought, but a feature like this would make the app less private: you would be able to pinpoint specific users to specific timezones, meaning you potentially locate them in specific parts of the globe.

I agree completely

It's worth noting that one of the proposed solutions above was to ask users for their exact location, and to write your bot to infer the timezone from that, and that solution would be a much, much worse location leak (admittedly, it would be an optional location leak which users would be aware of and have the chance to decline, so it still has its benefits)

a better idea would be a new markdown to show the time and date in their timezone.

This is definitely the best suggestion, In my humble opinion

I'm assuming that the goal is to display a particular time, written as human-readable time, in the reader's own timezone (and perhaps the reader's own locale-specific format?)

If that's the case, then this is a great suggestion. Telegram should provide a mechanism to for bots to submit a unix-time to Telegram, included as part of the message, and some kind of markup that would cause Telegram clients to display the time in a human-readable way

... except... I just realized that that means showing different text to different readers, for the same message. That would involve an update to the clients as well as the bot API. Damn...

[nmlorg]

Simple markup is how you end up with stuff like:

Event Alpha
Wed Jun 8 2:00 PM – Wed Jun 8 4:00 PM
Event Bravo
Sat Jun 11 8:00 PM – Sun Jun 12 1:00 AM
Event Charlie
Sun Jun 12 10:30 AM – Sun Jun 12 1:30 PM
Event Delta
Fri Jul 1 11:00 AM – Mon Jul 4 3:00 PM

instead of something like:

Event Alpha
Wed 8ᵗʰ, 2–4ᵖᵐ
Event Bravo
Sat 11ᵗʰ, 8ᵖᵐ – 1ᵃᵐ
Event Charlie
Sun 12ᵗʰ, 10:30ᵃᵐ – 1:30ᵖᵐ
Event Delta
Fri, Jul 1ˢᵗ, 11ᵃᵐ – Mon, Jul 4ᵗʰ, 3ᵖᵐ

That said, if that kind of logic were competently moved into the clients themselves, I'd love to just emit something like:

<date-range start="1654708000" end="1654710000">

I just don't want it to destroy readability.

[luisalvarado]

This would extremely useful for people like me because I always move all my clients to telegram. Basically I use telegram as my office platform for meetings, customer feedback and more. Some option on the group so they csn set their timezone and that way, when they type it tells me when they wrote that (similar to how fiverr shows it when talking to someone). That way there is no need to always ask for their time in order to coordinate meetings via telegram.

[JerakRus]

The issue of confidentiality is not entirely clear. After all, the task is not “get the time zone of the user’s location.” And the task is to get the “time zone that is configured on the user’s device for dates” in which the telegram itself shows all the dates. This setting does not tell us where the user is located.

In addition, there are a few more points - in WebApp it’s easy to get the user’s time zone, but for inline requests made to the bot @ there is no this information, and asking for the user’s time zone in some chat in response to his request also seems strange and an even bigger disclosure confidentiality.

In general it would be great to be able to get the time zone along with the language in the "from" object.

[levlam]

@JerakRus
How "asking for the user’s time zone in some chat in response to his request also seems ... an even bigger disclosure confidentiality" than always provide time zone for all users?

[JerakRus]

@levlam The permanent provision will only be to the bot or application, and the text message will be seen by all chat users.