My colleague Mingxue Zhao sent me a guest post designed to make sure that you are aware of an important time / clock issue.
The International Earth Rotation and Reference Systems (IERS) recently announced that an extra second will be injected into civil time at the end of June 30th, 2015. This means that the last minute of June 30th, 2015 will have 61 seconds. If a clock is synchronized to the standard civil time, it will show an extra second 23:59:60 on that day between 23:59:59 and 00:00:00. This extra second is called a leap second. There have been 25 such leap seconds since 1972. The last one took place on June 30th, 2012.
Not all applications and systems are properly coded to handle this “:60” notation. As a result, some applications or systems may malfunction and it is hard to predict which one will go wrong. To keep services stable, some organizations, including Amazon Web Services, plan to implement alternative solutions to avoid the “:60” leap second. This means that AWS clocks will be slightly different from the standard civil time for a short period of time.
If you want to know whether your applications and systems can properly handle the leap second, contact your providers. If you run time-sensitive workloads and need to know how AWS clocks will behave, read this document carefully. In general, there are three affected parts:
- The AWS Management Console and backend systems
- Amazon EC2 instances
- Other AWS managed resources
For more information about comparing AWS clocks to UTC, see the AWS Adjusted Time section.
AWS Management Console and Backend Systems
The AWS Management Console and backend systems will NOT implement the leap second. Instead, we will spread the one extra second over a 24-hour period surrounding the leap second by making each second slightly longer. During these 24 hours, AWS clocks may be up to 0.5 second behind or ahead of the standard civil time (see the AWS Adjusted Time section for more information).
You can see adjusted times in consoles (including resource creation timestamps), metering records, billing records, Amazon CloudFront logs, and AWS CloudTrail logs. You will not see a “:60” second in these places and your usage will be billed according to the adjusted time.
Amazon EC2 Instances
Each EC2 instance has its own clock and is fully under your control; AWS does not manage instance clocks. An instance clock can be affected by many factors. Depending on these factors, it may implement or skip the leap second. It may also be isolated and not synchronize to an external time system. If you need your EC2 instance clocks to be predictable, you can use NTP to synchronize your clocks to time servers of your choice. For more information about how to synchronize clocks, see the following documentation:
- Instances using Amazon Linux AMIs: Setting the Time for Your Linux Instance.
- Instances using Amazon-provided Microsoft Windows AMIs: Setting the Time for a Windows Instance.
- Instances using other AMIs: Please contact your AMI provider (the information in the preceding bullet points may also be helpful).
Adding the leap second is currently the standard practice. If you use public time servers, like time servers from ntp.org (the default for Amazon Linux AMIs) or time.windows.com (the default for Amazon Windows AMIs), your instance will see the leap second unless these synchronization services announce a different practice.
Other AWS Managed Resources
Other AWS resources may also have their own clocks. Unlike EC2 instances, these resources are fully or partially managed by AWS.
Clocks for the following resources synchronize to the time servers from ntp.org, which implements the standard leap second:
- Amazon CloudSearch clusters
- Amazon EC2 Container Service instances
- Amazon RDS instances
- Amazon Redshift instances
AWS Adjusted Time
This section provides specific details on how clocks will behave in the AWS Management Console and backend systems.
Starting at 12:00:00 PM on June 30th, 2015, we will slow down AWS clocks by 1/86400. Every second on AWS clocks will take 1+1/86400 seconds of “real” time, until 12:00:00 PM on July 1st, 2015, when AWS clocks will be behind by a full second. Meanwhile, the standard civil time (UTC) will implement the leap second at the end of June 30th, 2015 and fall behind by a full second, too. Therefore, at 12:00:00 PM July 1st, 2015, AWS clocks will be synchronized to UTC again. The table below illustrates these changes.
|UTC||AWS Adjusted Clock||AWS vs. UTC||Notes|
|11:59:59 AM June 30th, 2015||11:59:59 AM June 30th, 2015||+0||AWS clocks are synchronized to UTC.|
|12:00:00 PM||12:00:00 PM||+0|
|12:00:01||Each second is 1/86400 longer and AWS clocks fall behind UTC. The gap gradually increases to up to 1/2 second.|
|23:59:60||Leap second injected to UTC.|
|00:00:00 AM July 1st, 2015||-1/2||AWS clocks gain 1/2 second ahead of UTC.|
|00:00:00 AM July 1st, 2015||AWS clocks keep falling behind and the gap with UTC shrinks gradually.|
|12:00:00 PM July 1st ,2015||12:00:00 PM July 1st ,2015||+0||The gap shrinks to zero. AWS clocks synchronize to UTC again.|
— Mingxue Zhao, Senior Product Manager
Original URL: http://feedproxy.google.com/~r/AmazonWebServicesBlog/~3/y8Xrt85D_bM/