-4

I am using below code to fetch todays date but its giving me 20190909 for the first run and 20190910 for the second run.

I am running this at ny time 8:15pm onv 10sep2019.

LocalDate date = LocalDate.now(ZoneId.of("America/New_York"));
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyyMMdd");
System.out.println(formatter.format(date));

This is working fine in my local machine and uat server, only failing in qa server. I verified the time of the server and its fine.

Abhishek
  • 519
  • 1
  • 6
  • 24
  • what does it return if you run it *now*? change your pattern to display the time as well to get an idea what is happening and why. – luk2302 Sep 11 '19 at 13:33
  • 3
    Is your computer clock set correctly? What is the time zone setting of your computer? And of your JVM? What are you getting on the third run? I ran your code just now (with necessary corrections) and got `20190911` four times in a row, so cannot seem to reproduce. – Ole V.V. Sep 11 '19 at 13:34
  • I have provided timezone so the system time or zone would matter? – Abhishek Sep 11 '19 at 13:49
  • 1
    I don't think the `LocalDate.now(String)` method exists. Did you mean `LocalDate.now(ZoneId.of("America/New_York"))`? Or did I miss something? – MC Emperor Sep 11 '19 at 13:54
  • @Abhishek `.now(Zone)` implementation is a single line: `return now(Clock.system(zone));`, so yes it does use system time. – Nexevis Sep 11 '19 at 13:54
  • What i am suspecting is when i keep the app running it somehow uses the first date always may be caching or something and when i restart the app it works fine. When you run 4 times in a row you get the same response but if you leave the program running till the next day and see what it return, in my case its still returning the first date. – Abhishek Sep 11 '19 at 14:10
  • One possible explanation would be: Your QA server time zone has been set to America/Nome (Alaska) or some other time zone at an offset around -08:00, probably by error. Someone who didn’t know adjusted the time to agree with New York time, so around 8 last night its clock was 8 Nome, the same as 12 midnight in New York. So when you ran your snippet shortly before 8 PM, it printed the day before, and when you ran it again shortly after 8 PM, it printed the expected date. When you check the computer clock, it shows the expected NY time. But you need to check the time zone setting too. – Ole V.V. Sep 11 '19 at 14:14
  • `LocalDate.now` doesn’t cache. If the call happens at a point, it may read the clock, and if the thread somehow hangs for a long time (don’t know how it could, though), it may return a result from that clock reading even though time has moved forward in the meantime. I consider it a very unlikely explanation for your observed results. – Ole V.V. Sep 11 '19 at 14:22
  • Another possible explanation would be if in your real code you keep the `date` object around. In this case it will keep its value (`LocalDate` objects are immutable) and still show the same date if you print it hours or days later. – Ole V.V. Sep 11 '19 at 14:29
  • The above code is in a static function and the calling method stores the date returned in final local variable, its not a global variable – Abhishek Sep 11 '19 at 15:06
  • I tried `Executors.newScheduledThreadPool(1).scheduleAtFixedRate(() -> { System.out.println(LocalDate.now(zone)); } , 0, 1, TimeUnit.MINUTES);` and let it run until past midnight in the time zone (Asia/Chita in my case). The output changed nicely from `2019-09-11` to `2019-09-12` as expected. – Ole V.V. Sep 11 '19 at 15:24

1 Answers1

0

This is working just fine as expected, there was some other lib issue which i have fixed.

Thanks

Abhishek
  • 519
  • 1
  • 6
  • 24