0

This question is quite close to mine, However I find the answer not suitable for me. I have timestamp as Long.

ts = 1362156863140L

As it is Long I consider it as timezone naive timestamp, is that right? It is timestapm in local time in Cologne - UTC+0200 (CET). So when I convert it to String timezone aware timestamp I want to obtain:

2013-03-01T14:54:23.140Z

or

2013-03-01T16:54:23.140+02:00

I'm using solution from answer in the beginning of my question:

Instant.ofEpochMilli(timestamp).atOffset(ZoneOffset.of("+2"));

which returns:

2013-03-01T18:54:23.140+02:00

another timezone:

Instant.ofEpochMilli(timestamp).atOffset(ZoneOffset.of("Z"));

returns:

2013-03-01T16:54:23.140Z

So those methods does not really change the timezone, they just change representation of timestamp. I also tried another method:

OffsetDateTime.ofInstant(Instant.ofEpochMilli(timestamp), ZoneId.of("UTC"));

But results are exactly the same. This solutions was useful, but original approach:

int offset = TimeZone.getTimeZone("Europe/Amsterdam").getRawOffset();
long newTime = timestamp - offset;

does not concider summer/winter time. And suggested answers use Calendar class, which is obsolete for JDK8. What works and is obvious enough is:

OffsetDateTime.ofInstant(Instant.ofEpochMilli(Timestamp), ZoneId.of("UTC")).minusSeconds(7200);

But it is defenetly not a proper way to do this, so how can I do that with timezone?

Charlie4fun
  • 197
  • 2
  • 16
  • Your question is too broad? Tell us exactly what you need? – Ravindra Ranwala May 29 '18 at 12:32
  • How to convert this 1362156863140L to that 2013-03-01T14:54:23.140Z – Charlie4fun May 29 '18 at 12:34
  • 1
    "As it is Long I consider it as timezone naive timestamp". I'd say the opposite. Given that a long cannot (easily) contain timezone information, it is not portable to store it this way. A long timestamp must be an instant in time irrespective of a time zone (i.e. a Unix timestamp). – Michael May 29 '18 at 12:41
  • This is what I am getting for your input timestamp value. `2013-03-01T21:24:23.140` – Ravindra Ranwala May 29 '18 at 12:55
  • Either your assumptions are wrong or your long value is. A long value like yours would normally denote a number of milliseconds since the epoch of Jamuary 1, 1970, 00:00 UTC. Understood this way, your long value denotes `2013-03-01T16:54:23.140Z`, not `2013-03-01T14:54:23.140Z` (`Z` means UTC). If someone gava you the long value and intended the latter, they did things in a non-standard way that is bound to cause confusion. And if so, I don’t know how they would have handled summer time, so I also cannot tell you how you should handle it. – Ole V.V. May 29 '18 at 18:35

1 Answers1

1

I suppose that timestamp is in UTC and you need to change timestamp to CET. Take a look at withZoneSameInstant() method, might be helpful.

    long timeStamp = 1362156863140L;
    ZoneId sourceZone = ZoneId.of("UTC");
    ZoneId targetZone = ZoneId.of("CET");
    String s = ZonedDateTime.ofInstant(Instant.ofEpochMilli(timeStamp), sourceZone)
            .withZoneSameLocal(targetZone)
            .toString();
    System.out.println(s);
jahra
  • 1,173
  • 1
  • 16
  • 41
  • I finally used that: `Instant.ofEpochMilli(timestamp).atOffset(ZoneOffset.of("Z")).withOffsetSameLocal(ZoneOffset.of("+2"));` but I still have no idea how to handle summer time – Charlie4fun May 29 '18 at 15:42
  • 1
    Don’t rely on three letter time zone abbreviations, they are not standardized and not unique. For the time in Köln/Cologne I suggest `ZoneId.of("Europe/Berlin")`. Your code reflects a good guess at how to interpret the asker’s long value, but we cannot be sure. – Ole V.V. May 29 '18 at 18:38
  • 1
    @Charlie4fun ZonedDateTime handles summer/winter time automatically as far as I know, but you should use ZoneId rather then offsets like "+2" – jahra May 29 '18 at 18:40