0

My epoch value is 3 days ahead of the actual time passed as input.

I have a date 2023-03-21T04:34:12.234567800Z in which 00Z is the offset, but once I convert it to epoch in java, I am getting an epoch output which is 3 days ahead of the time in the actual date given above? Any idea on how we can form date format for Dates having offset 00Z. I am using this format ->"yyyy-MM-dd'T'HH:mm:ss.SSS'Z'"

This is the code snippet I have worked upon

public class date_to_epoch {

    public static void main(String[] args) {
        //The date format against which the Date will be matched
        SimpleDateFormat df = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSSSSSSSS");
        //Timezone
        df.setTimeZone(TimeZone.getTimeZone("(UTC+05:30) Asia/Kolkata"));
        try {
            @SuppressWarnings("unused")
            String rtValue="2023-03-21T04:34:12.234567800Z";
            Date date = df.parse("2023-03-21T04:34:12.234567800Z");
            SimpleDateFormat utcformat = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSSSSSSSS");
            utcformat.setTimeZone(TimeZone.getTimeZone("UTC"));
            rtValue = utcformat.format(date);
            long epoch = date.getTime(); // timestamp value received in rt field of log to epoch
            String sDatetime = String.valueOf(epoch);
            System.out.println(sDatetime);
            
        } catch (Exception ex) {
        }
        
    }
}

1679607819800--> This was the epoch I am getting, which corresponds to a date three days ahead, So I am not able deduce the Date format for in this. enter image description here

Ole V.V.
  • 81,772
  • 15
  • 137
  • 161
Nagesh R Shanbhag
  • 1
  • 1
  • 2
    "in which 00Z is the offset" - are you sure? That looks like a timestamp with nanosecond precision, and "Z" to indicate UTC. How are you parsing? What do you mean by "epoch output"? As Chaosfire says, a [mcve] is the way forward here - but I'd also strongly encourage you to re-examine your assumption that all of "00Z" is the offset. – Jon Skeet Mar 27 '23 at 09:55
  • //The date format against which the Date will be matched SimpleDateFormat df = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSSSSSSSS"); //Timezone df.setTimeZone(TimeZone.getTimeZone("(UTC+05:30) Asia/Kolkata")); – Nagesh R Shanbhag Mar 27 '23 at 11:01
  • To add on to this I have also tried Date format as yyyy-MM-dd'T'HH:mm:ss.SSSSSSSSS'Z', but doesn't match with the Date-Time provided – Nagesh R Shanbhag Mar 27 '23 at 11:20
  • 4
    I strongly recommend that you don’t use `SimpleDateFormat`, `Date` and `TimeZone`. THey were all poorly designed, the first in particular notoriously troublesome. And all are long outdated. Also there never was a way that `SimpleDateFormat` could support neither 7 nor 9 decimals on the seconds, which is the reason for your incorrect value. Instead [java.time, the modenr Java date and time API,](https://docs.oracle.com/javase/tutorial/datetime/index.html) handles your string easily. `Instant.parse("2023-03-21T04:34:12.234567800Z").toEpochMilli()` yields 1 679 373 252 234. – Ole V.V. Apr 04 '23 at 07:57
  • 3
    Other points: 1. Never swallow exceptions. An empty catch block is a dirty no-no and will give you dire trouble sooner or later. And in experimental code and code under development rather sooner than later. 2. The trailing `Z` in your string is an offset of zero from UTC and needs to be parsed as an offset (which you didn’t), 3. `UTC+05:30) Asia/Kolkata` is not a valid time zone and does not give you the time zone that you think. Use the modern `ZoneId` and it will notify you through an exception -- only, then don’t swallow the exception, as I said. – Ole V.V. Apr 04 '23 at 07:57
  • @OleV.V. Thank you very much for the suggestion, Will take this as a learning. – Nagesh R Shanbhag Apr 05 '23 at 14:02

0 Answers0