7 Replies Latest reply: Sep 21, 2009 1:40 PM by jschellSomeoneStoleMyAlias RSS

    Handling 64 bit time

    807580
      Hi
      i have a requirement to read a 64 bit time from a byte array and convert into time stamp. Please can anyone help me out?
        • 1. Re: Handling 64 bit time
          DarrylBurke
          Insuffucient information. How exactly is the time stored in the byte array?

          db
          • 2. Re: Handling 64 bit time
            807580
            It is a 64 bits field: 32 bits for the seconds + 32 bits for the nano-seconds.
            The 4 bytes seconds field correspond to the number of seconds since the system epoch (0h00 GMT, 1st January, 1970),
            and the 4 bytes nanosecond field correspond to the number of remaining nanoseconds.
            Is this info sufficient?
            • 3. Re: Handling 64 bit time
              807580
              new Timestamp(seconds * 1000L + nano-seconds / 1000000L)
              Taking care to make sure the sign of the seconds and nan-seconds is corrected according to your specification for the two fields.
              • 4. Re: Handling 64 bit time
                807580
                32 bit signed for seconds from unix epoch (Jan 1 1970) rolls over in the year 2038. Be careful!
                • 5. Re: Handling 64 bit time
                  807580
                  Thanks for your reply. Its working! I need one more guidance...
                  When i make the
                  seconds = 0, for the purpose of testing
                  instead of displaying TimeStamp to be Jan 1, 1970 00:00:00
                  its displaying it as Jan 1,1970 05:30:00

                  Which means its automatically taking into consideration my systems time zone of +05:30 i suppose.
                  Is there a way to get the timestamp in the UTC itself regardless of whats my local timezone in the system?
                  Means i need to decode the seconds to absolute time...
                  • 6. Re: Handling 64 bit time
                    807580
                    wizsen wrote:
                    Thanks for your reply. Its working! I need one more guidance...
                    When i make the
                    seconds = 0, for the purpose of testing
                    instead of displaying TimeStamp to be Jan 1, 1970 00:00:00
                    its displaying it as Jan 1,1970 05:30:00

                    Which means its automatically taking into consideration my systems time zone of +05:30 i suppose.
                    Is there a way to get the timestamp in the UTC itself regardless of whats my local timezone in the system?
                    Means i need to decode the seconds to absolute time...
                    Timestamp and java.util.Date are defined to store the time as milliseconds since 1/1/1970 UTC. The toString() method of Timestamp and Date create a String based on your default Timezone. If you want a display String in UTC then use SimpleDateFormat.format() and set the Timezone of the SimpleDateFormat instance to UTC.
                    • 7. Re: Handling 64 bit time
                      jschellSomeoneStoleMyAlias
                      sabre150 wrote:
                      wizsen wrote:
                      Thanks for your reply. Its working! I need one more guidance...
                      When i make the
                      seconds = 0, for the purpose of testing
                      instead of displaying TimeStamp to be Jan 1, 1970 00:00:00
                      its displaying it as Jan 1,1970 05:30:00

                      Which means its automatically taking into consideration my systems time zone of +05:30 i suppose.
                      Is there a way to get the timestamp in the UTC itself regardless of whats my local timezone in the system?
                      Means i need to decode the seconds to absolute time...
                      Timestamp and java.util.Date are defined to store the time as milliseconds since 1/1/1970 UTC.
                      Emphasizing that point ...

                      The data in java.util.Date is always in UTC. When you call Date(long date) that sets the data directly - thus the point above that it is in UTC.