Epoch time, Do most people know ?

I just learned this (59 yrs old and still learning, who'd have thunk) . Do people know about Epoch Time ?
Simply, its the time in seconds (32 bit value) since 1/1/1970. It expires or rolls over in 1938 or sometime about then.
I know anyone can figure this out , when I started tracking seconds on PIC with longs, that will go for 68 years before rollover !!!! Just thought that was pretty cool.
With the Epoch time value, its GMT and apparently (obviously) they subtract the seconds-in-a-hour to match your time zone. Don't know yet how to retrieve this val from someware.
Also, (I know anyone can figure this out) there are only about 8000 hours in a year, and if you sleep and eat for 10 hrs a day your down to 4 to 5000 hrs left. And work takes up min 2000/yr.
The point is, not a lot of time left after necessities to enjoy.

Attachment 6006
Don

Quote:

---

Originally Posted by amgen

I know anyone can figure this out , when I started tracking seconds on PIC with longs, that will go for 68 years before rollover !!!! Just thought that was pretty cool.

---

Unless I'm making some dumb mistake, I think 32 bits will give enough seconds to go for 136 years.

(2^32) / (3600*24*365) = 136 years

And, yes life is too short for all the things that we would like to do.

Robert

Hi Robert,
You bring up a good point, an issue thats not always clear. Indeed 32 bit is some 4 Billion count unless it is Signed, then its half + & -.
The PBP manual says Longs are treated as signed. Info on the web said that Epoch time was a signed value, but on the Epoch info web you can put bigger values than 2.5 billion in the calc date and get a future date in what should be the (-) values.
I think it just shows that you have to know the intended use and MIN and MAX values of what your working with.
I tried out incrementing a long when it rolls over from 2^31, it displays continued count using DEC, but using SDEC, it rolls to -2^31 then counts down minus on increment. I know thats what it should do, just makes it a little clearer.

This is with SDEC modifier:
Attachment 6010
Don
amgen

This thread came up pretty convenient as I've been working on my W5100 code to do SNTP - and now it does - just.
The difference between epoch and SNTP is apparently that with epoch we start counting at 1/1-1970 while with SNTP we start at 1/1-1900. So going from SNTP timestamp to epoch is just a matter of subtracting 70 years worth of seconds

I'm stuffing the 32bit timestamp from the server into two words which I now would like to convert to a more understandable format - like time of day and perhaps even date. If anyone has PBP code etc for this I'd love to see it.

/Henrik.

But if you are trying to translate NETWORK time, that is the time from Jan 1, 1900

The code below takes a "brute force" approach, but works. I'm sure some math whiz could
certainly come up with a better formula.



HOffset = Local offset from GMT
Sign = 1 if you are EARLIER than GMT
Sign = 2 if you are LATER than GMT ("+")
DST = 1 if you are using DST

The program takes a "shortcut" in that it calculates time since Jan 1, 2000

Code:

---

 
              IF sign = "1" then
                  if DST = 1 and HOffset = 0 THEN
                      Sign = "2"
                      GOTO OtherSide
                  ENDIF   
                   
                    TimeNow = Timenow - ((HOffset - DST) * 3600)
              ENDIF
           
OtherSide:           
              IF Sign = "2" THEN
             
                  TimeNow = TimeNow + ((Hoffset + DST) * 3600)
              ENDIF 
                                   
                SINCEJAN2009 = TIMENOW - 3439756800  ; 3439756800 is the #of sec from Jan1 1900 to Jan1 2009
             
                RUNNINGSECONDS = SINCEjAN2009
                YR = 2009
               
GETYEAR:
       
                    LEAP = (YR//4)    ; = 0 if leap year
                   
                    if LEAP = 0 then
                        SecondsInYear = 31622400 ;366*60*60**24
                   
                    ELSE
                        SecondsInYear = 31536000 ;365*60*60*24
                   
                    endif
                     
                    If RunningSeconds > SecondsInYear Then
                        RunningSeconds = RunningSeconds - SecondsInyear
                        YR = YR + 1
                        GOTO GetYear
                    ENDIF
             
                Mo = 1 ; Start with Month = 1 
               
       
GETMONTH:       
                IF LEAP > 0 THEN
                  lookup2 MO,[0,2678400,2419200,2678400,2592000,2678400,2592000,2678400,2678400,2592000,2678400,2592000,2678400],SecondsInMonth
                ELSE
                  LOOKUP2 MO,[0,2678400,2505600,2678400,2592000,2678400,2592000,2678400,2678400,2592000,2678400,2592000,2678400],SecondsInMonth
                ENDIF
               
                If RunningSeconds >= SecondsInMonth THEN
                  RunningSeconds = RunningSeconds - SecondsInMonth
               
                MO = MO + 1
                GOTO GETMONTH
                ENDIF 
FINDDAYS:
       
                DA = RUNNINGSECONDS/86400
                RUNNINGSECONDS = RUNNINGSECONDS//86400
   
                HR = RUNNINGSECONDS/3600
                RUNNINGSECONDS = RUNNINGSECONDS//3600
     
                MN = RUNNINGSECONDS/60
                RUNNINGSECONDS = RUNNINGSECONDS//60
                SC = RUNNINGSECONDS
           
                Da = Da + 1
              HSEROUT [13,10,13,10,DEC2 HR,":",DEC2 MN,":",DEC2 SC,"  ",DEC2 MO,"/",DEC2 DA,"/",#YR,13,10]

---

Hi Charles,
Exactly, with SNTP "time began" at 1/1-1900.
I see your code uses LONGS which I'm trying to avoid but I'll digest it and see what might come out, thanks for sharing, I appreciate it!

/Henrik.

I guess that I left out some stuff in the code above.

It is designed for use with a Lantronix XPort. It logs on to port 123 of timeservers and comes back with network time.
And, yes, you ***MUST*** use 18F chips!



The stuff that goes before it is -

Code:

---

THEADER[0] = $2          ' STX

        THEADER[1] = TSIP1  ' DESTINATION IP
        THEADER[2] = TSIP2
        THEADER[3] = TSIP3
        THEADER[4] = TSIP4

        THEADER[5] = 0            ; DESTINATION PORT HIGHBYTE
        THEADER[6] = 123          ; DESTINATION PORT LOWBYTE
                   
        LRC1 = 0
        LRC2 = 0
     
        For X = 1 to 6
            LRC1 = LRC1 ^ THeader[x]
        next X
                     
        THEADER[7] = LRC1             
        THEADER[8] = 0             
        THEADER[9] = 48                                            'Data Length lowbyte
   
;Send the header
     
          For X = 0 to 9
            HSEROUT2 [THeader[X]]
          Next X 
       
          LRC2 = LRC2 ^ THeader[8]
          LRC2 = LRC2 ^ THeader[9]
       
;Send the data
          HSEROUT2 [$1B]
          LRC2 = LRC2 ^ $1B
          For X = 0 To 46
            HSEROUT2 [0]
            LRC2 = LRC2 ^ 0
          NEXT X   
                 
;Send the Checksum (LRC)           
       
          HSEROUT2 [LRC2]
getresponse:       
         
   
        HSERIN2 1000,NoResponse,[Wait($2)]                                                     
        hserin2 200,NoResponse,[SKIP 41,TimeNow.Byte3,TimeNow.Byte2,TimeNow.Byte1,TimeNow.Byte0]

---

Thanks Charles,
I'm using the 18LF46K22 and W5100 ethernet chip, the SNTP stuff are done and I get the seconds count from the server, no issues there. It's the conversion from seconds to true time that's bugging me and the reason I'm trying to avoid longs is that it adds a lot of overhead to the program even in sections not actually using longs.

I'm on my way to convert your convert-routine to use 16 bit variables but it does get a bit messy...

Thanks again for sharing!
/Henrik.

It shouldn't be too bad - breaking it into 16 bit 'chunks' , you will just have an offset that is not just hours, but hours, minutes and seconds.