使用Python发送短信；考虑时区的时间延迟

发布于 2024-12-04 19:14:27 字数 463 浏览 1 评论 0原文

因此，我有一个代码可以接收移动设备的相关信息，例如电话号码、姓名和消息，通过这些信息可以发送短信。此外，还有延迟短信的功能。因此，用户可以使用下拉菜单选择稍后发送消息。此外，延迟函数还会检查消息发送时间是否在 12:00am 到 8:00am 之间，如果是，则返回默认值 8:00am，这样接收方将在 8:00am 收到消息。最早。然而我面临的问题是，时间延迟是按照山地夏令时间（加拿大/美国）计算的，这意味着居住在 PDT 时区的人们将在上午 7:00 收到消息（太早了），而居住在 EDT 的人们将在上午 7:00 收到消息（太早了）上午 10:00 收到消息（晚了 2 小时）。所以我想知道是否有一些 python 代码可能会检测接收者所在的时区，以便他/她准时收到消息（如果我在内华达州选择上午 8:00，那么加利福尼亚州的接收者将在上午 8:00 PDT），给定接收器所在的区域（例如，给出的代码表明接收器位于加利福尼亚州）。

关于如何解决这个问题有什么想法吗？

谢谢！

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

捶死心动 2024-12-11 19:14:27

快速而肮脏：您可以通过让用户说出事件应在多少小时/分钟后发生来避免该问题。那么他们当地的时区是什么并不重要。

更好：如果您能够获取手机上的当地时间以及 UTC 时间（无论是从手机还是从您的服务器），这将告诉您 UTC 偏移量 的电话。大多数时候你都可以逃脱惩罚。但 UTC 偏移量与本地时区不同。在夏令时或夏令时边界附近，当您假设 UTC 偏移量与时区相同时，诸如“明天同一时间”之类的想法就会失效。

最佳：为了正确支持政治时区政策，Olson 数据库无可替代。使用 Olson 意味着您的应用有一个配置项供用户设置时区（例如：America/New_York 和 Etc/UTC）。您可以根据电话和手机号码的 UTC 偏移量（使用其他答案中详细介绍的查找表）选择默认值，并且在大多数情况下都是正确的。

在 Python 中， pytz 模块为您提供了一个非常干净的 API，用于使用 Olson 数据库来使用datetime 对象。

编辑：在给定时区对象的情况下，此函数会将 Unix 时间转换为本地化 datetime 对象：

def localize_epoch_time(epoch_time, timezone=pytz.UTC):
  u"Given an epoch time return an accurate, timezone-aware datetime object"
  t = localtime(epoch_time)
  epochdt = datetime(*(t[:6] + (int((epoch_time - long(epoch_time)) * 1000000), timezone)
  if hasattr(timezone, 'normalize'):  # pytz tzinfo objects have this
    return timezone.normalize(epochdt)
  else: # tzinfo object not from pytz module
    return epochdt

Quick and Dirty: You could dodge the problem by getting the user to say after how many hours/minutes the event should occur. Then it doesn't matter what their local time zone is.

Better: If you have the ability to get the local time on the phone, as well as the UTC time (either from the phone or from your server), that will tell you the UTC offset of the phone. You can get away with that most of the time. But UTC offset is NOT the same thing as a local time zone. Near a daylight-savings or summer-time boundary, ideas like "the same time tomorrow" break when you assume that the UTC offset is the same as the time zone.

Best: For supporting political time zone policies correctly, there is no substitute for the Olson database. Using Olson would imply that your app has a configuration item for the user to set their timezone (examples: America/New_York and Etc/UTC). You might choose defaults for this based on the UTC offset of the phone and the mobile number (using lookup tables as detailed in the other answers) and be correct most of the time.

In Python the pytz module gives you a very clean API for using the Olson database to work with datetime objects.

EDIT: This function will convert Unix time to a localized datetime object, given a timezone object:

def localize_epoch_time(epoch_time, timezone=pytz.UTC):
  u"Given an epoch time return an accurate, timezone-aware datetime object"
  t = localtime(epoch_time)
  epochdt = datetime(*(t[:6] + (int((epoch_time - long(epoch_time)) * 1000000), timezone)
  if hasattr(timezone, 'normalize'):  # pytz tzinfo objects have this
    return timezone.normalize(epochdt)
  else: # tzinfo object not from pytz module
    return epochdt

回复收藏 0 原文