From the course: Java SE 21 Developer (1Z0-830) Cert Prep

Time-zone considerations, part 1 - Java Tutorial

From the course: Java SE 21 Developer (1Z0-830) Cert Prep

Time-zone considerations, part 1

(no audio) - Let's review a few essentials about time zones. The first observation is that 6:00 PM January 4th, 2023 does not actually represent a unique moment in history, but potentially something like 38 different moments. There are being more than 24 time zones because there are some that are offsets that are not whole hours. So if a time zone is included with a date and time, then it does represent a unique moment in history. But equally, two different statements of date, time, and time zone might actually represent the exact same moment. So for example, when it's February 2nd at 6:00 PM in Denver, Colorado, it's actually February 3rd at 9:00 AM in Beijing. Now there is a class, ZoneId, which is the base class and primary means of describing a time zone in Java's APIs. ZoneId generally includes region information and rules about changes to offsets, the kind of thing that you get when you get daylight savings time. ZoneOffset is actually a subtype of that which is used for fixed offsets, just a numerical offset that doesn't change. It doesn't have a region name, nor does it have time changing rules. Time zone rules will describe things that are usually called gaps and overlaps. A gap is what you get when the clock is moved forward. So it goes directly from say 2:00 AM to 3:00 AM and there is no 10 past two in the morning during that time zone change. By contrast, an overlap represents the clock jumping backwards. Let's take a look at some of this in code examples. So the first thing we might need to do is to actually find out what the known time zone IDs actually are. So if we have the ZoneId class, we can get available ZoneIds from it. That is an iterable, so we can just run a for each on it and print them all out. There's going to be quite a lot of these. You'll see that all kinds of stuff. There's the US Pacific Time Zone, America, Los Angeles, as we scroll back, UCT, Hong Kong, and so forth, a great many of these. But those are all the time zones that are actually known to the Java system. We can also create one directly by name. I'm gonna comment those two lines out because they'll generate rather too much output if we keep using them. If I say ZoneId of, we actually did this in a previous segment, I can say Europe slash Paris and I will get this ZoneId which I can then do things with, for example, print it. Just print its own name, nothing terribly exciting. In addition, we can extract from a ZoneId, this time we go to Berlin, we can get the rules. And the rules is a table of information that includes all the transitions. And this again is an iterable, so we can just print them all out. And from there you can see we have a lot of transitions. We have overlaps and gaps and overlaps and gaps. You'll notice as a matter of historical amusement, we start with a gap in 1893 and then nothing much happens until 1916. And then we get a few years of changes and then some more breaks and then it starts changing fairly regularly. And around about 1997, Germany adopted European rules and therefore this set of rules has no more entries because those rules are standardized in Europe-wide rules. But nevertheless, you can see how this set of information would allow us to determine when and how to make time zone changes. Of course, one of the things we might want to do is starting from a given point in time, find out when we will next be subject to one of these changes. In this case, if we go and get the rules, we can ask for the next transition subsequent to a given moment in time. And if we just ask for an instant of now and we will find the next time zone change. This notice is the rules on ZI, which was the European Paris rules, though I'm fairly sure those are the same as the Berlin ones, and that was the whole point about their standardized now. As a reminder, everything up to 1997 were German time zone changes. This last one is the next time zone change for Paris 2023, month 10 is October, on the 29th, 0300 plus two to plus one. So we will fall back in Paris one hour at 2:00 AM. We'll get that overlap back to 1:00 AM on the 29th of October. In addition to going for the next transition, we can ask about the previous transition and that will give a similar kind of information, except, of course, in this case this was a gap. So it was a spring forward and in this case on the 26th of March, it went from plus one to plus two hours. So if we use that now, we can actually look at how the time zone change affects time calculations. So here we'll have a zoned date time, which we will pass from input text to be March 25th at midnight in the Paris time zone. So we're just a little ways shy of the time zone change where Paris sprang forward at that point in time. If we then print out various values from this, we'll print the initial time just to validate that's what we had. Then we will add 24 hours to it. Now notice we're adding 24 hours, not one day. Then we'll add 48 hours and 72 hours. So a day, two days, and three days but done in terms of hours. And that will take us over that time zone change. And you'll notice that we go March 25th at midnight, March 26th at midnight, and then March 27th, we're now at 1:00 AM but the time zone has shifted. So it is 24 hours later, but the representation has changed. Then we do another 24 hours and go to 72 and we are now still at 1:00 AM and still in the new time zone. (keyboard clacks) Let's put a separator in there. And then if instead we were to add days, we notice something slightly different. Again, this is probably what you'd expect. When we add one day from the 25th, we get to the 26th and we're still at midnight. We add another one day or we add the two days and we're still at midnight. We add three days, we're still at midnight, but the time zone has changed. So the difference between there and there is no longer 24 hours, but it counts as one day in human calendar terms.

Contents