We add the date header when signing the request and just use System.currentTimeMillis corrected for any potential clock skew error between client and service. Could you try logging the values of System.currentTimeMillis() and SDKGlobalTime.getGlobalTimeOffset() to see if they are returning sensible values?

I'm having this issue now as well.

Here are a few examples of the times you asked for, logged just before calling a method on the S3 client library:

2015-08-11 00:14:07.731  INFO 1 --- [pool-4-thread-1] x.RedshiftEtl  : System.currentTimeMillis(): 1439252047731
2015-08-11 00:14:07.731  INFO 1 --- [pool-4-thread-1] x.RedshiftEtl  : SDKGlobalTime.getGlobalTimeOffset(): 0

2015-08-11 00:12:07.419  INFO 1 --- [pool-4-thread-1] x.RedshiftEtl  : System.currentTimeMillis(): 1439251927419
2015-08-11 00:12:07.425  INFO 1 --- [pool-4-thread-1] x.RedshiftEtl  : SDKGlobalTime.getGlobalTimeOffset(): 0

2015-08-11 00:13:37.346  INFO 1 --- [pool-4-thread-1] x.RedshiftEtl  : System.currentTimeMillis(): 1439252017346
2015-08-11 00:13:37.346  INFO 1 --- [pool-4-thread-1] x.RedshiftEtl  : SDKGlobalTime.getGlobalTimeOffset(): 0

Thanks @rehevkor5, that all looks normal. Are you configuring the client or request object before making the call? If possible could you turn on wire logging and paste a sample request, please note wire logs may contain sensitive information depending on your application so take care and review and redact if needed.

http://docs.aws.amazon.com/AWSSdkDocsJava/latest/DeveloperGuide/java-dg-logging.html

This are values returned before exception.

System.currentTimeMillis(): 1439277525424
SDKGlobalTime.getGlobalTimeOffset(): 0

The code works on my machine, on remote machine which runs integration tests, but fails at development environment.

Ok, I think I have something. The failing machine runs the code on docker container using "java:8" base image. It is open JDK 8. I see that they made some update 4 days ago, which might be problem.
docker-library/openjdk@6f34072
I will try to downgrade to previous tag and let you know the result.

Changing openJDK docker base image from java:8 to java:8u45 fixed the issue. "java:8" currently points to openjdk-8u66-jdk so I guess there is some new bug/problem.

Here is the diff that helped me to figure out that I should use java:8u45
docker-library/docs@358b772#diff-db78c7f2f1969a2e1b5c9aa31e0fbc9aL7

Ahhh my memory has failed me. This appears to be related to #444. Can you check what version of joda time is being resolved in your maven dependencies?

I'm using joda-time 2.7

Upgrading to at least joda-time 2.8.1 should allow you to use Java 1.8u60 and higher. If another portion of your dependency graph is causing 2.7 to be pulled in declaring a direct dependency on 2.8.1 will take precedence.

It fixed issue. I recommend to write about it somewhere (FAQ, requirements) because I wasn't able to google it using exception message

Will do @ppiotrow. Thanks for reporting this.

Chiming in @shorea to let you know the joda-time work around did not work for me. I'm using OpenJDK8_u66, aws-java-sdk-s3 1.10.11, and joda-time 2.8.1 but I'm still receiving the same S3 authentication error that @ppiotrow reported.

@gibbonsj are you sure 2.8.1 is the version being used at runtime? Can you try starting your application with the "-verbose:class" option to see where the joda time classes are being loaded from?

new DateTime().getClass().getProtectionDomain().getCodeSource() may also work if it's easier for you to just add a print statement in your application.

@shorea, the work around is good. Long story short, the code was using an older joda-time from a TPS fat jar. Once the class path was fixed everything worked perfectly. Thank you again.

Great to hear!

I was just bitten by this defect while building a Docker image that uses the maven:3-jdk-8 base image; the base image was updated to use Java 8u66 since the last time I committed.

I'm building a Dropwizard 0.8.1 app, and Dropwizard has a dependency on joda-time 2.7 which is vulnerable to this issue. I pinned joda-time to 2.8.1 in my Maven pom.xml, rebuilt the image, and all is well.

Update JodaTime version above 2.0 and serializer your atribute

// serializer Joda DateTime
public class JodaDateTimeSerializer extends JsonSerializer<DateTime> {

    private static DateTimeFormatter formatter = DateTimeFormat.forPattern("yyyy-MM-dd HH:mm:ss.SSSZ");

    @Override
    public void serialize(DateTime value, JsonGenerator gen, SerializerProvider arg2) throws IOException, JsonProcessingException {
        gen.writeString(formatter.print(value));
    }                       

]

// Deserializer Joda DateTime
import java.io.IOException;

import org.joda.time.DateTime;
import org.joda.time.format.DateTimeFormat;
import org.joda.time.format.DateTimeFormatter;

import com.fasterxml.jackson.core.JsonParser;
import com.fasterxml.jackson.core.JsonProcessingException;
import com.fasterxml.jackson.databind.DeserializationContext;
import com.fasterxml.jackson.databind.JsonDeserializer;

public class JodaDateTimeDeserializer extends JsonDeserializer<DateTime> {

    private static DateTimeFormatter formatter = DateTimeFormat.forPattern("yyyy-MM-dd HH:mm:ss.SSSZ");

    @Override
    public DateTime deserialize(JsonParser jsonParser, DeserializationContext context) throws IOException, JsonProcessingException {
        String date = jsonParser.getText();
        return formatter.parseDateTime(date);
    }
}


In your class

@JsonSerialize(using = JodaDateTimeSerializer.class)
@JsonDeserialize(using = JodaDateTimeDeserializer.class)
private DateTime created;