[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.

[nmlorg]

@JerakRus
For what it's worth, my bot only asks the user for their location in private chats; there's no way to trigger that flow in a group. (Even when configuring how the bot behaves in a group, a group admin has to change the settings using private messages to the bot.)

[JerakRus]

@NMorg Location demand - greatly reduces the conversion of users to the bot. For example, as a user, I don’t want to share my location, but I don’t mind if the bot knows my time zone to display the data correctly. In addition, it is not always possible to accurately determine the time zone by location - there are still countries with several zones or, conversely, with several locations - but they have different time zones.

[nmlorg]

@JerakRus You're repeating some of the earlier discussion.

I think the options so far are:

1. Have TBA provide the user's Olson zone in User records. This would require clients to send that data (or the user's current location) to Telegram, for Telegram to pass (or calculate) that information to TBA, and for TBA to pass (or calculate) that information to bots.
    
   Since there's a many-to-one mapping between Olson zones and countries, it would make sense for TBA to explicitly include the user's country code in User records as well.
   • Note that the language_code field used to include the user's country code, but it silently disappeared roughly 6 years ago. It's not clear if that was a bug fix, a change to intended policy, or if the removal was an accident.
2. Have TBA resume sending the user's country code (ideally in an explicit country_code field).
   • For most countries, this is sufficient to determine local time; but for most users, this will only slightly simplify the process of prompting them to provide their time zone.
3. Have TBA send the user's current UTC offset.
   • This will allow bots to localize the current time correctly, but may introduce confusion around DST switchovers.
4. Add a request_timezone button to KeyboardButton.
   • This wouldn't significantly affect privacy, but would still require an explicit configuration step for every user.
5. Introduce a message entity that clients replace with the localized time.
    
   This would have to be accepted by TBA, passed through Telegram, and implemented in every individual client.
   • Frankly, Telegram client maintainers are a little too opinionated for me to trust them with this. For example, Web A goes to the trouble of using Number.toFixed to convert 2120 / 1000 to '2.1', then uses String.replace to change the locale-correct "2.1K" to incorrect/confusing "2,1K" (etc.).
   • Even just somehow enforcing that clients use the OS'/browser's localization system unmolested would still likely lead to loss of control over things like countdowns, adding little "soon" emojis, etc.
6. Explicitly recommend that bots prompt users for exact location (using request_location) and then geocode themselves.
   • Geocoding is probably more complicated than most entire bot projects. At bare minimum, it introduces a new live-service dependency.
   • I don't need to know my users' exact location for any other purpose. I'll probably use it if I start getting it for free, but I currently don't prompt for it even though I could.
7. Explicitly recommend that bots move [part of] their UIs from Telegram messages to a Mini App, which would be able to query the browser for time zone (etc.).
   • Not all official clients support Mini Apps. There's no degraded experience; Mini Apps are just "unsupported messages".
8. Explicitly recommend that bots move [part of] their UIs from Telegram messages to a standalone web page, which would be able to query the browser for time zone (etc.).
   • Sending messages from standalone web pages through Telegram to bot accounts is not very straightforward.
   • Adding/opening up a directly browser-accessible web server would introduce significant new coding challenges/security liabilities.

 
I think my preference would be:

1. Give all bots all users' time zones. All web pages have the ability to passively get/record/report visitors' time zones, so there's at least some precedent for that to not be considered protected PII.
2. Add the ability to grant access (permanently until revoked) to a bot to include my time zone in every message.
3. Develop essentially a [nearly] Turing-complete language that can be included as markup in Telegram messages that would run inside users' clients (with access to localized time-formatting primitives).
   • I just want to be able to do things like specify "if the date is a different month, include the localized month".
   • It must be 100% impossible for client maintainers to force rules like "day before month", 24-hour time, etc.
4. Add a request_timezone button to KeyboardButton.

[JerakRus]

Thank you for such a detailed answer. Indeed, I could have repeated myself because I did not see all the previous discussions, for that I apologize. But judging by the fact that there is no functionality, the discussions came to conclusions that seemed strange to me and at the same time complicate third-party development, so I raised the question again. Of the options you proposed, for many factors it seems to me that 1 is the most suitable.