6

I have a linux machine, and its time zone is set as Asia/Qatar. When I am printing Instant.EPOCH with formatter its giving me wrong zone information while for Instant.now() the zone information is correct. Below is my code and its output. Can anyone please help me, why is this discrepancy?

import java.util.Date;
import java.time.format.DateTimeFormatter;
import java.time.Instant;
import java.time.ZoneId;

public class DateTest {
   public static void main(String[] args) {
      String pattern = "yyyy-MM-dd'T'HH:mm:ss.SSS Z";
      Instant myInstant = Instant.EPOCH;
      Instant myInstantNow = Instant.now();
      DateTimeFormatter formatter =  DateTimeFormatter.ofPattern(pattern).withZone(ZoneId.systemDefault());
      System.out.println(formatter.format(myInstant));
      System.out.println(formatter.format(myInstantNow));
   }
}

The output of the code is:

1970-01-01T04:00:00.000 +0400
2019-09-29T18:30:14.766 +0300

Java version: "1.8.0_181"

Same code if I run in windows, its working fine. I am getting +0300 for Instant.EPOCH as well.

Ole V.V.
  • 81,772
  • 15
  • 137
  • 161
Miracle
  • 61
  • 4
  • 1
    Which time zone is your Windows computer set to? I believe that Windows time zones are different, so Asia/Qatar probably isn’t a selectable option in the Windows settings? Also is your Windows computer running Java version 1.8.0_181 too? – Ole V.V. Sep 29 '19 at 17:11

2 Answers2

8

TL;DR: Your results from Linux are correct and as expected.

In 1970 Qatar was at offset +04:00 from GMT. The epoch is January 1, 1970. In 1972 Qatar changed from offset +04:00 to +03:00. Source: On Time Zone in Doha, Qatar (Ad Dawhah), in the Time zone changes for: dropdown select 1970–1979.

What went wrong on your Windows computer, then? It’s a guess on my part: The way I read Default Time Zones in the Windows documentation, Windows does not offer an Asia/Qatar time zone as a setting in Windows. So my guess is that your Windows is set to Arab Standard Time according to the table I just linked to, which in turn translates to UTC+03:00. Arab Standard Time (or Arabia Standard Time; abbreviated AST) is used in for example Kuwait, Iraq and Yemen too. But those countries have been on offset +03:00 all the time since 1970 and before. So when Java tries to pick up the default time zone from Windows, it could easily get a time zone with this history rather than the correct history for Qatar. As I said, it’s a guess for now. But you can easily verify. On your Windows computer try:

    System.out.println(ZoneId.systemDefault());

If it prints Asia/Qatar, my guess was wrong. If it prints something like GMT+03:00, I was right. If it prints something else, I may or may not be.

Edit: A couple of further links: AST – Arabia Standard Time (Standard Time) gives Kuwait as an example city. Time Changes in Kuwait City Over the Years infomrs us that Kuwait too has been on offset +03:00 since 1950.

Further edit: Thanks for confirming that Java on your Windows computer prints Asia/Riyadh as its default time zone. Riyadh, Saudi Arabia, has been on offset +03:00 since 1947. This at least partly explains why you get this offset even though it’s not correct for Qatar. Source

Ole V.V.
  • 81,772
  • 15
  • 137
  • 161
1

At the first observation I though the daylight saving time difference takes place since your dates show January (wintertime) and September (summertime), however as far as I see Qatar doesn't use this system nowadays.

However, when we take a look into the past, we can find out that Qatar changed the UTC zone on the 1st of July 1972 from GST (-04:00) to AST (-03:00) so I guess the results are correct. This information might be found at Time Zone & Clock Changes in Doha, Qatar.

The problem is that the Windows machine uses the current Qatari UTC since Windows-based platform tracks some history. Read more at Are Windows timezone written in registry reliable?.

Nikolas Charalambidis
  • 40,893
  • 16
  • 117
  • 183
  • 5
    Interesting. But the JVM has its own time zone data. Does it use the Windws time zone data at all? (I haven’t got a Windows computer to test on.) – Ole V.V. Sep 29 '19 at 16:58
  • As far as I know, this information comes from the underlying OS and takes the zonal information from the registry. I am not aware that JVM does keep an internal running clock itself. I might be wrong, though, but it sounds reasonable to me. – Nikolas Charalambidis Sep 29 '19 at 17:02
  • 3
    The JVM does not keep its own clock, but its own time zone data. That’s why we need the [Timezone Updater Tool](https://www.oracle.com/technetwork/java/javase/documentation/tzupdater-readme-136440.html) for keeping it up to date on older Java installations/versions. – Ole V.V. Sep 29 '19 at 17:04
  • 1
    Qatar has never observed Daylight Saving Time (DST). The wording in your first paragraph is misleading on this point. – Basil Bourque Sep 30 '19 at 06:57
  • @BasilBourque: I stated “At the first observaton...” and “...Qatar doesn’t use”. I feel it’s pretty clear that my initial thoughs aimed to the DST and I found a solution anywhere else. I am not a native speaker so I admit I might be wrong - would you rephrase it? Feel free to do so :)) – Nikolas Charalambidis Sep 30 '19 at 11:27
  • 1
    @Nikolas I like your interest in how to make your post even clearer. I think it often (though not always) helps if we omit the thought process we’ve been going through and just present the conclusion. IMO, one option here is to leave out the introduction and start from “when we take a look into the past…”. If you want, you may at the end add something like “We can rule out DST as a source of the problem since Qatar doesn’t use DST.” Just my 0.02 thought. – Ole V.V. Sep 30 '19 at 14:35
  • @Nikolas I agree with comment by Ole V.V. The phrasing with "doesn't use this system nowadays" suggests that they *did* use the system in the past. Your own link (on 4th tab) says: “Daylight Saving Time has never been used here.”. I suggest you too state the fact just as plainly. Also, it would be nice to cite a more scholarly source on the recent history of timekeeping in Qatar, but I could not find one. – Basil Bourque Oct 01 '19 at 21:24
  • On a different topic: As Ole V.V.’s first comment says, the OpenJDK-based implementations of Java keep their own internal copy of the [tz database](https://en.wikipedia.org/wiki/Tz_database). The tracking of time zone history of MS Windows operating system is irrelevant, as far as I know, except for the aspect described in the [Answer by Ole V.V.](https://stackoverflow.com/a/58157300/642706). – Basil Bourque Oct 01 '19 at 21:27