0

I have a unique issue where I have to determine 2 things.

1) if my current time and a custom time are within the same 30 min time slot ( say its 2:10pm and the custom time is 2:22pm , I want to see they are within the same time slot from 2 to 2:30 ) but shouldn't be in the same time slot if current time is 1:55pm and custom time is 2:15pm (30 min difference but not within the same device/clock time slot as one is 1:30 to 2pm and another is 2 to 2:30pm)

2) Now, within the same time slot of 30 mins, if current time is before the custom time, I want to return a true, else return a false. any way to calculate this? I am looking to add a custom function in my common utils class where I can feed it custom time and current time and see the result, so would be useful to have something generic. Any ideas?

I have looked at : Check if a given time lies between two times regardless of date and other articles but nothing describes the 30 min device/clock time slot period.

Any idea if https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/time/DateUtils.html will somehow help me manipulate this exact logic or any custom function/library in android helps with this. will be really helpful!

  • Which API you are currently using for Date Time ? `Calendar` or DateTime API or any other `Joda-Time` of `ThreeTenBNP` ? The [link](https://stackoverflow.com/questions/17697908/check-if-a-given-time-lies-between-two-times-regardless-of-date) you have added has answer for your que . The only thing i see is that you need to calculate two Dates for intervals first which will act as start and End time .. – ADM Jun 10 '19 at 10:53
  • I am using ThreeTenBNP in other parts of my code, but not sure how to go about this one since its based in a clock time slot. How do I calculate the 2 dates for intervals in 30 mins clock slots? –  Jun 10 '19 at 11:00
  • If it not found in the library, then you can implement it via a utility function. I have done similarly by using **ChronoUnit**. For your case logic will be the difference should be <= 30 Minute and it should lie in the same slot. – nagendra patod Jun 10 '19 at 11:27
  • but how do I get the same slot based on device or clock time? if you can explain your answer with code ,it will be useful –  Jun 10 '19 at 11:50
  • we can take minutes part from dates and for same time slot, both minutes should be less than 30 or greater than 30. Please try it yourself, if needed I can explain it with code. – nagendra patod Jun 10 '19 at 12:03
  • I tried it, but no luck which is why I posted this question. I couldn't figure out a simpler way to do this, if you can explain it with code, it will be really helpful and if it works ,I will mark your answer as correct! –  Jun 10 '19 at 12:51
  • Please find my answer. Hope it will work. – nagendra patod Jun 10 '19 at 13:19
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/194703/discussion-between-nagendra-patod-and-angela-heely). – nagendra patod Jun 10 '19 at 13:20

1 Answers1

-1
package Demo;

import java.time.LocalDateTime;
import java.time.temporal.ChronoUnit;
import java.util.Arrays;
public class Test1 {
    public static void main(String arg[]) {
        LocalDateTime ct = LocalDateTime.now();
        LocalDateTime custemTime = ct.plusMinutes(5);
        System.out.println(ct);
        System.out.println(custemTime)  ;
        System.out.println(isInSameSlots(ct,custemTime));

    }   
    static boolean   isInSameSlots(LocalDateTime ldt1, LocalDateTime ltd2) {
        Long timeDiff = ChronoUnit.MINUTES.between(ldt1, ltd2);
        if(timeDiff > 30 || timeDiff < 0) 
           return false;
        return (ldt1.getMinute() <= 30 && ltd2.getMinute() <= 30) || (ldt1.getMinute() > 30 && ltd2.getMinute() > 30 ) ? true : false; 

    }

}

case 1

2019-06-10T18:40:09.122

2019-06-10T18:45:09.122

true

Case 2 ) 2019-06-10T18:46:56.350 2019-06-10T19:06:56.350 false

nagendra patod
  • 289
  • 2
  • 8
  • This seems good! just one issue is my custom time is not a localdatetime format, its a Date format. How do I compare a localdatetime and date? –  Jun 10 '19 at 13:35
  • you mean it is **java.util.Date** type. if it is Date type then we can convert it in LocalDateTime by using below line d1.toInstant().atZone(ZoneId.systemDefault()).toLocalDateTime(); anyway we do not have to use **java.util.Date** . as in java8 there is better suport for date and time functinality via LocalDate and LocalDateTime – nagendra patod Jun 10 '19 at 13:50
  • awesome, will test it out and let you know how it works. thanks! –  Jun 10 '19 at 14:00
  • works well thanks! can you help with another similar logic issue that i m facing , will post the code for that shortly in another question –  Jun 10 '19 at 17:12
  • 3
    FYI, `LocalDateTime` is the wrong class to use here. That class cannot represent a moment, as discussed in its Javadoc. I cannot think of a case where calling `LocalDateTime.now()` is the right thing to do. Instead use `Instant`, `OffsetDateTime`, or `ZonedDateTime`. – Basil Bourque Jun 10 '19 at 21:42
  • thanks @AngelaHeely, It will be my pleasure to help you further in any issue related to coding and logic. – nagendra patod Jun 11 '19 at 05:06
  • @Basil , you are correct . LocalDateTime is a human representation of date and time and instant is a count of nanoseconds since the epoch of the first moment of 1970 UTC. But I havn't found anything wrong in LocalDateTime as it can be parsed as according to the timezone in which we are using. **LocalDateTime.now()** Obtains the current date-time from the system clock in the default time-zone. https://docs.oracle.com/javase/8/docs/api/java/time/LocalDateTime.html https://stackoverflow.com/questions/56424566/java-time-localdate-vs-instant-for-a-business-date – nagendra patod Jun 11 '19 at 05:24
  • By using `LocalDateTime` you are needlessly discarding valuable information (the zone or offset) with *nothing gained!* When receiving data about a monetary amount, would you choose to strip away the part indicating the currency (US dollars vs British pounds vs Euros)? – Basil Bourque Jun 11 '19 at 15:40
  • Your definition of `LocalDateTime` is incorrect. There is **no concept of UTC** in `LocalDateTime`. Having no concept of time zone or offset-from-UTC is the entire point of `LocalDateTime`. Your definition fits `Instant` rather than `LocalDateTime`. – Basil Bourque Jun 11 '19 at 17:41