4 ms·

"Between 5:25 PM and 6:07 PM PDT we experienced an Internet connectivity issue with a provider outside of our network. The issue has been resolved and the servi

by verelo 11y ago

"Between 5:25 PM and 6:07 PM PDT we experienced an Internet connectivity issue with a provider outside of our network. The issue has been resolved and the service is operating normally. " http://status.aws.amazon.com/ http://status.aws.amazon.com/ I really hate how AWS use PDT for their status page. Seriously, is there any logical reason to use anything other than UTC? I find it means when there is a report, I first need to convert the PTD time shown to UTC, then to local time just so I can know if the issue is possibly the one I experienced. Unless you're also in PDT, couldn't they just save everyone else one step by showing all service issues in UTC?

jonas21 11y ago
Whichever time zone you pick, everyone not in that time zone is going to have to do a conversion. So why not pick the time zone where most of Amazon's engineers, and quite possibly most of their customers' engineers, are located?
- joshribakoff 11y ago
  PDT differs from PST. Conversion logic can get especially confusing if you've specified a date time, and then the laws surrounding day light savings time are changed to occur on a different day. Using UTC is like using a unix timestamp, you don't have to worry about a lot of things like locales & local laws, when the date time was recorded vs when its being viewed & what laws might have changed in-between. For example the date/time that daylight savings takes effect was changed in 2007. If you're trying to compare old logs to an old AWS announcement, it could get confusing... whereas UTC should remain immune to changes in laws.
  - verelo 11y ago
    This is exactly why I want UTC timestamps.
source99 11y ago
What percentage of admins(or people that care about these status) are in PDT compared to the rest of the world? If it's in UTC then everyone would have to do one conversion instead of nearly all people doing 1 conversion. Also I know my offset from PDT but I don't know my offset from UTC so it's also saving me the step of having to lookup that offset also.
michaelkeenan 11y ago
A Google query helps with this. For example, search for: 6:07 PM PDT to HKT Google will return a special result at the top of the page: "6:07 PM Tuesday, Pacific Time (PT) is 9:07 AM Wednesday, Hong Kong Time (HKT)"

by verelo 11y ago

jonas21 11y ago

Whichever time zone you pick, everyone not in that time zone is going to have to do a conversion. So why not pick the time zone where most of Amazon's engineers, and quite possibly most of their customers' engineers, are located?

joshribakoff 11y ago
PDT differs from PST. Conversion logic can get especially confusing if you've specified a date time, and then the laws surrounding day light savings time are changed to occur on a different day. Using UTC is like using a unix timestamp, you don't have to worry about a lot of things like locales & local laws, when the date time was recorded vs when its being viewed & what laws might have changed in-between. For example the date/time that daylight savings takes effect was changed in 2007. If you're trying to compare old logs to an old AWS announcement, it could get confusing... whereas UTC should remain immune to changes in laws.
- verelo 11y ago
  This is exactly why I want UTC timestamps.

source99 11y ago

What percentage of admins(or people that care about these status) are in PDT compared to the rest of the world? If it's in UTC then everyone would have to do one conversion instead of nearly all people doing 1 conversion. Also I know my offset from PDT but I don't know my offset from UTC so it's also saving me the step of having to lookup that offset also.

michaelkeenan 11y ago

A Google query helps with this. For example, search for: 6:07 PM PDT to HKT Google will return a special result at the top of the page: "6:07 PM Tuesday, Pacific Time (PT) is 9:07 AM Wednesday, Hong Kong Time (HKT)"