Epoch time, Do most people know ?

[amgen]

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.

6006
Don

[rsocor01]

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

[amgen]

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:
6010
Don
amgen

[HenrikOlsson]

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.

[Charles Linquis]

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




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]

[HenrikOlsson]

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.

[Charles Linquis]

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 -





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,TimeN ow.Byte0]

[HenrikOlsson]

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.

[Charles Linquis]

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.