0

The code simply extract the time portion of two timestamps and sub them from each other to get the duration

import java.util.Calendar;
public class Test {

    public static void main(String[] args) {
        Calendar cal = Calendar.getInstance();
        cal.setTimeInMillis(1659304800000L);
        getTimePortionFromCalendar(cal);
        Long startMillis = cal.getTimeInMillis();
        cal.setTimeInMillis(1660089600000L);
        getTimePortionFromCalendar(cal);
        Long endMillis = cal.getTimeInMillis();
        long duration =endMillis - startMillis;

        System.out.println(duration);
    }

    private static void getTimePortionFromCalendar(Calendar start) {
        start.set(1970,Calendar.JANUARY,1, start.get(Calendar.HOUR_OF_DAY), start.get(Calendar.MINUTE), start.get(Calendar.SECOND));
    }
}

Using eclipse and intelliJ yielded the expected answer (7200000) while all online compilers such as https://www.tutorialspoint.com/compile_java_online.php

https://www.onlinegdb.com/online_java_compiler

https://www.programiz.com/java-programming/online-compiler/

https://www.jdoodle.com/online-java-compiler/

printed (-79200000) as the result

Any Idea why ?

Ole V.V.
  • 81,772
  • 15
  • 137
  • 161
A.Alqadomi
  • 1,529
  • 3
  • 25
  • 33
  • 5
    Very likely a timezone difference. However, in general I advice against using java.util.Calendar etc. but go for the newer java.time API. – Thomas Aug 10 '22 at 07:50
  • 2
    Maybe an other Timezone? – Jens Aug 10 '22 at 07:50
  • 2
    This is almost certainly a timezone issue. Can you explain (in English) what it is you are trying to do? Where do the two long values come from? What do they represent and what calculation do you want to do? – Joachim Sauer Aug 10 '22 at 08:30
  • 1
    I strongly recommend you don't use `Calendar`. That class was cumbersome and error-prone to work with and is now long outdated. I think you want `Instant.ofEpochMilli(1_659_304_800_000L).atZone(ZoneId.of("Asia/Qatar")).toLocalTime()`. And similar for the end time. And then you want `Duration.between()` for the -- well, the name says. One of the many advantages of java.time, the modern Java date and time API. – Ole V.V. Aug 10 '22 at 08:51
  • 2
    In UTC -- a likely default time zone for an online compiler -- your start time is at 22:00 and end at 00:00, so the correct and expected difference is -22 hours, which is what you got. In Qatar, for example, the times are 01:00 and 03:00 and the difference +2 hours, which is what you got locally. In many other time zones you will too. – Ole V.V. Aug 10 '22 at 08:52
  • @JoachimSauer the values are static ones that I have used just to check the result, I know that the diff between them is 7200000 and wanted to use them to test the logic . the reason behind this code is that we have a system that is providing events and with each there is a start and end timestamps . I want to insert them to the android calendar system in a correct way so I need to calculate the duration of the event on each day and the number of days to supply them to the android calendar intent in a format that is understandable to the calendar app. – A.Alqadomi Aug 10 '22 at 09:42
  • @A.Alqadomi: If I understood correctly, you must consciously decide which timezone you do that calculation in, which you don't do anywhere in your code, which is why it probides different results when run on different systems (which use different default timezones). And I echo everyone elses suggestion: don't use `java.util.Calendar` (or `java.util.Date` for that matter), switch to the much saner API in `java.time` instead. – Joachim Sauer Aug 10 '22 at 09:44
  • @OleV.V. your answer makes total sense to me.can you please provide it as an answer to I can select it . as for why I don't use the newer APIs I am developing for android and I got warning that these APIs require level 26 . I think I need to make some changes to migrate to the new APIs – A.Alqadomi Aug 10 '22 at 09:48
  • 2
    @A.Alqadomi: you can use most of `java.time` on Android by using [desugaring](https://developer.android.com/studio/write/java8-support-table) and it's definitely a worthwhile path. – Joachim Sauer Aug 10 '22 at 11:20
  • @JoachimSauer Thanks for the suggestion . I just included the desugaring in the project today. – A.Alqadomi Aug 10 '22 at 11:40
  • You don't need to rewrite all use of the old date and time classes when you introduce java.time. The two can live happily side by side for many years. For when you need to interface old code, the old classes after desugaring come with conversion methods to and from the new types. – Ole V.V. Aug 10 '22 at 13:55
  • And thanks for trusting me to write an answer. I no longer contribute answers here for reasons that I try to explain in [my profile](https://stackoverflow.com/users/5772882/ole-v-v). I you want to key in the answer yourself, I shall be happy to upvote. – Ole V.V. Aug 10 '22 at 13:56

0 Answers0