• Post Reply Bookmark Topic Watch Topic
  • New Topic

Question about java.time.temporal  RSS feed

 
Wazim Karim
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

Just signed up; here goes my first post. I just program for pure fun. As far as experience, I don't know where I stand.  I know some basic stuff. (I can solve around 80 percent of the problems on coding bat's java section).  Whatever I've learned has been through pure trial and error.  I refer to my learning style as "Brute Force Learning"; lol.  I try and try until I get it right.  So having said that; here's my question.  I'm learning to use the time package in java, and it's pretty straight forward; I get the gist of it. But I keep getting hung up on the "idea" of the temporal interface. By "Idea" what I mean is; I don't understand how the word temporal relates to time (the dictionary's definition didn't help either). Is it some measurement of time? A unit of time? Some "Building Block" of time?? The more I read into this package the more I start questioning my understanding of time in general (yes I understand that machine time is different than human time). I guess I'm used to looking at a clock and observing the time. To me, time is what I observe on a clock. I've never sat and thought about the "concept of time". So the word "Temporal" is really tripping me up. I'm just not seeing the big picture. I'm stuck between "I kinda get it; but I don't really get it". And my OCD won't let me get past it; .

Anyone care to elaborate?

Thanks,

 
Stephan van Hulst
Saloon Keeper
Posts: 7963
143
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"Temporal" is an adjective that means "relating to time". We often use adjectives for interface names, for instance "Comparable".

In java.time.*, something is Temporal if it can be used to express a moment in time - with a certain precision - and if you can add some amount of time to it to get a new moment in time. It does not have to express a unique moment in time.

Some examples:
  • LocalTime expresses a moment within a day, with precision in nanoseconds. You can add hours, minutes, seconds, milliseconds and nanoseconds to it to get a new LocalTime. It does not express a unique moment in time, because different days may use the same local time.
  • LocalDate expresses a moment within an era, with precision in days. You can add years, months and days to it to get a new LocalDate. It does not express a unique moment in time, because different time zones may use the same local date.
  • YearMonth expresses a moment within an era, with precision in months. It's the same as LocalDate, except that it doesn't contain a day field.


  • Some counterexamples:
  • MonthDay expresses a moment within a month, with precision in days. You can NOT add months or days to it to get a new MonthDay, because not all months have the same amount of days.
  • DayOfWeekAndDayOfMonth, if it existed, couldn't express a moment reliably, because the fields may contradict each other. For instance, "Friday the 13th" may contradict itself if for a particular month, the 13th is a Tuesday.
  •  
    Tony Docherty
    Bartender
    Posts: 3271
    82
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    And Welcome to the Ranch
     
    Campbell Ritchie
    Marshal
    Posts: 56522
    172
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Wazim Karim wrote:. . .  I know some basic stuff. (I can solve around 80 percent of the problems on coding bat's java section).
    Codingbat is good for testing whether you have implemented your algorithms wrongly or correctly. It used to be called Javabat. It doesn't however check the style of your code.
    Whatever I've learned has been through pure trial and error.  I refer to my learning style as "Brute Force Learning"; lol.  I try and try until I get it right.  So having said that; here's my question.
    Trial and error is not necessarily the best way to learn; you will learn what is bad soon enough, but you may not necessarily learn the best way to do things.If you can find somebody competent to teach you, that shou‍ld teach you both what to avoid and what to do.
    I'm learning to use the time package in java, and it's pretty straight forward; I get the gist of it.
    You don't know how straightforward the java.time package is until you have tried the dreadful classes which preceded it.
    . . . I don't understand how the word temporal relates to time (the dictionary's definition didn't help either). . . .
    Do you mean temporal or Temporal? The two are different. I think what happened is that when the new classes were designed (heavily influenced by a framework which I haven't used, but it is highly spoken of) called Yoda Time, some of the obvious names like Date and Calendar has already been used, so they had to think of different names. So you end up with slightly awkward names, whose meaning has to be invented tweaked to fit the framework's requirements. Read more about the java.time package in the Java™ Tutorials.

    And welcome to the Ranch again.
     
    Stephan van Hulst
    Saloon Keeper
    Posts: 7963
    143
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Wazim Karim wrote:To me, time is what I observe on a clock.

    This is very dangerous thinking. "Time" refers to different things. Besides a "time as indicated on a clock", there's a "point in time", an "amount of time", a "period of time" and maybe some others I haven't thought of. These are all different things.

    There's only one class in the java.time library that represents only "time as indicated on a clock", and that's the LocalTime class. If you take the related clock off the wall, and put in a room in a different timezone, it's useless.

    Imagine a clock on the wall that has a sign underneath indicating the timezone of that clock:


    You can remove such a clock and its sign, put it in a room in a different time zone, and what it reads will still make sense, but ONLY if you also know what day it is. The related class is ZonedDateTime. The reason it still makes sense, is because it identifies a unique "point in time": two different observers will agree on the point in time it indicates, even if they live in different places. Two other classes that have the same property are OffsetDateTime and Instant. Two different observers can agree on the point in time they indicate, because they both use a fixed time zone: UTC. The Instant class completely hides this though, you can just imagine this as an arrow pointing to a location on a huge time-line of historical events.

    Instant and ZonedDateTime use completely different internal fields to identify the unique point in time. Intant just records the number of seconds and nanoseconds since the 1st of January 1970, UTC. ZonedDateTime records a year, month, day, number of hours, minutes, seconds, nanoseconds and a timezone.

    Now, while LocalDateTime may indicate a "time on a clock", it doesn't indicate a unique "point in time", but you can still imagine adding and subtracting "amounts of time" from it. That's exactly what you do when you turn the wheel on the back of your analog clock! That's why it implements Temporal.
     
    Wazim Karim
    Greenhorn
    Posts: 4
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    To everyone who've replied; Thank You!
     
    Campbell Ritchie
    Marshal
    Posts: 56522
    172
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    That's a pleasure
     
    Consider Paul's rocket mass heater.
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!