Post by: SMcNeill on August 20, 2019, 12:55:30 am
Code: QB64: [Select]
- _LIMIT 10
- PRINT "HAPPY NEW YEARS!!!!"
- 'Based on Unix Epoch time, which starts at year 1970.
- 'Minor fixes to leap year logic by Bplus. Many thanks!
- d = d + 365
- d = d + 1 'add an extra day for leap year every 4 years, starting in 1970
- s~&& = d * 24 * 60 * 60 'Seconds are days * 24 hours * 60 minutes * 60 seconds
- TimeStamp## = (s~&& + t##)
Function gives a timestamp based on Unix Epoch Time, when we give it a date a time. Simple enough, and thanks go to Bplus for helping catch a logic error in the leap year calculations.
Post by: STxAxTIC on August 20, 2019, 06:21:44 am
I can see that this code should replace the existing code in the Toolbox, no problem... But without studying the issue at all, I have a naive question - why did the function pass the test that led to the (obligatory) screenshot? Adjusting for local time it seemed correct - even when compared to the freebasic timecore and the one i translated for sxript. We all agreed on that test. Was the bug deep enough that only certain dates would trigger it? (Sorry, didn't read into this at all yet.)
Post by: SMcNeill on August 20, 2019, 06:37:40 am
Code: [Select]
FUNCTION ExtendedTimer##
d$ = DATE$
l = INSTR(d$, "-")
l1 = INSTR(l + 1, d$, "-")
m = VAL(LEFT$(d$, l))
d = VAL(MID$(d$, l + 1))
y = VAL(MID$(d$, l1 + 1)) - 1970
FOR i = 1 TO m
SELECT CASE i 'Add the number of days for each previous month passed
CASE 1: d = d 'January doestn't have any carry over days.
CASE 2, 4, 6, 8, 9, 11: d = d + 31
CASE 3: d = d + 28
CASE 5, 7, 10, 12: d = d + 30
END SELECT
NEXT
FOR i = 1 TO y
d = d + 365
NEXT
FOR i = 2 TO y STEP 4
IF m > 2 THEN d = d + 1 'add an extra day for leap year every 4 years, starting in 1970
NEXT
d = d - 1 'for year 2000
s~&& = d * 24 * 60 * 60 'Seconds are days * 24 hours * 60 minutes * 60 seconds
ExtendedTimer## = (s~&& + TIMER)
END FUNCTION
The glitch was in this little line of code:
IF m > 2 THEN d = d + 1 'add an extra day for leap year every 4 years, starting in 1970
So if January and February, we didn’t add a day for each leap year...
The fix is as in the first post above; let the loop go to Year - 1 (don’t check the current year yet), and simply add one for each leap year. Then check to see if the current year is leap year, and if so, is it after februrary where we need to count that extra day.
Note: TimeStamp and ExtendedTimer are very similar functions, but slightly different, TimeStamp lets you specify a time and date, creating a UET value for that moment; ExtendedTimer works exclusively with your current date and time, as a replacement for the TIMER command.
Corrected version of ExtendedTimer is as follows:
Code: QB64: [Select]
Or, for the minimalist folks out there, if they like TimeStamp, they could also have a quick version for:
Code: QB64: [Select]
Post by: STxAxTIC on August 20, 2019, 06:46:37 am
So bplus hinted that this bug propagated out of the Toolbox somehow - does the Extended Timer code need to be updated? If it did something so wrong with leap years, then why did the screenshot check out?
Or is that code fine as-is?
Gotta fly - I won't be able to hit this again for 12 hours so...
Post by: SMcNeill on August 20, 2019, 06:54:18 am
Alright -
So bplus hinted that this bug propagated out of the Toolbox somehow - does the Extended Timer code need to be updated? If it did something so wrong with leap years, then why did the screenshot check out?
Or is that code fine as-is?
Gotta fly - I won't be able to hit this again for 12 hours so...
The screenshot checks out because we're currently past the 2nd month...
IF m > 2 THEN d = d + 1 ... We didn't need that IF check in there; we needed one after for the current year only.
Change is to replace:
Code: [Select]
FOR i = 2 TO y STEP 4
IF m > 2 THEN d = d + 1 'add an extra day for leap year every 4 years, starting in 1970
NEXT
d = d - 1 'for year 2000With:
Code: [Select]
FOR i = 2 TO y - 1 STEP 4 'from 1972 onwards, skipping the current year.
IF i <> 30 THEN d = d + 1 'add an extra day for leap year every 4 years, starting in 1970, but skip year 2000
NEXT
IF m > 2 AND (y MOD 4 = 2) THEN d = d + 1 'fix for leap year, for the current year.As long as your current month was > 2, the existing code worked out right. You just suddenly lost out on a bunch of leap days when Jan/Feb rolled around, to gain them all back once we were March again. ;)
Post by: bplus on August 20, 2019, 09:51:41 am
Code: QB64: [Select]
- 'IF i <> 30....
This could be replaced by: d = d + y * 365 ' y or y -1 ?????????? OK y I think
Code: QB64: [Select]
Update:
but now, I am wondering should't this be to y-1 as we count the days in y the partial year separately.
EDIT Update: No y starts at 0 not 1, so not y-1...
OK I am writing a tester for this Function. Starting at 01-01-1970, 0 time should be 0
Post by: bplus on August 20, 2019, 12:06:26 pm
This probably offsets all time##, so when compare differences in date and time will be OK but calc of absolute seconds from 01-01-1970 will be off a day = 86400 secs.
Post by: SMcNeill on August 20, 2019, 12:38:28 pm
Update: If timestamp##("01-01-1970", 0) should be 0, it is a whole day off.
This probably offsets all time##, so when compare differences in date and time will be OK but calc of absolute seconds from 01-01-1970 will be off a day = 86400 secs.
And, to think, we could avoid all these issues if we just used c++ to give us the solution in one line:
Code: C++: [Select]
- double now = std::chrono::duration_cast<std::chrono::seconds>(std::chrono::system_clock::now().time_since_epoch()).count();
There’s a page here which can be used to compare results: https://www.epochconverter.com/
Somehow, I was matching results before; how the heck did I break things so we’re off so badly now? I’ll dig into it later this evening when my time frees up a little again. ;)
(And I’ll probably add that single line into my repo and just make an _EXTENDEDTIMER command and use it. I imagine it’d be much faster than doing all the calculations manually anyway.). ;)
Post by: bplus on August 20, 2019, 02:46:37 pm
Quote
There’s a page here which can be used to compare results: https://www.epochconverter.com/
OK it does look like 0 AM Jan 1, 1970 is suppose to be 0 at GMT:
So far minimal testing subtracting 1 from d, just after it is calc'd from date$. OK
Kinda makes sense to subtract a day from the date because it isn't complete yet, the fraction of it is in the time.
Post by: bplus on August 20, 2019, 08:46:48 pm
I caught another bug on day counts and I think I have worked up a fix, leap year again or rather not a leap year this time! Be right back! Still running checks with my code tester.
Good that was the last bug for day counts anyway.
The last bug was about checking for leap year for y. We forgot to consider if y is year 2000 which is NOT a leap year.
Here is my test code that tests day counts from 01-01-1970 to 01-01-2035 by comparing the day count current test date to the day count for the test date for day before, if the day count <> last day count + 1 the code stops running on the error producing date.
Code: QB64: [Select]
- ' Steve's TimeStamp## even better than Toolbox tool!
- d = 0: m = 1: yr = 1970
- d = d + 1
- 'is it leap year
- m = 3: d = 1
- 'd is ok
- m = 3: d = 1
- m = 3: d = 1
- m = m + 1: d = 1
- d = 1: m = 1: yr = yr + 1
- d = 1: m = m + 1
- d1$ = "01-01-1970"
- a## = TimeStamp##(d1$, 5)
- b## = TimeStamp##(d2$, 5)
- moda## = BmodTimeStamp##(d1$, 5)
- modb## = BmodTimeStamp##(d2$, 5)
- dab& = (a## - b##) \ 1
- PRINT dab&
- flagNeg = -1: dab& = -dab&
- flagNeg = 0
- days% = dab& \ (86400)
- dab& = dab& - days% * 86400
- hours% = dab& \ 3600
- dab& = dab& - hours% * 3600
- minutes% = dab& \ 60
- secs% = dab& - minutes% * 60
- moddab& = (moda## - modb##) \ 1
- modflagNeg = -1: moddab& = -moddab&
- modflagNeg = 0
- moddays% = moddab& \ (86400)
- moddab& = moddab& - moddays% * 86400
- modhours% = moddab& \ 3600
- moddab& = moddab& - modhours% * 3600
- modminutes% = moddab& \ 60
- modsecs% = moddab& - modminutes% * 60
- 'PRINT "Updated 2019-08-20 10:58 AM if i <> 30 fix from if y <> 30"
- PRINT "Steve TimeStamp## Function:"
- PRINT "Difference between A## and B##:"; days%; "days,"; hours%; "hours,"; minutes%; "minutes,"; secs%; "secs, ";
- PRINT "B## was later than A##"
- PRINT "A## was later than B##"
- PRINT "Difference between mod A## and mod B##:"; moddays%; "days,"; modhours%; "hours,"; modminutes%; "minutes,"; modsecs%; "secs, ";
- PRINT "mod B## was later than mod A##"
- PRINT "mod A## was later than mod B##"
- 'INPUT "OK ... press enter "; w$
- lastDay% = moddays%
- _LIMIT 1000
- PRINT "Done!"
- _DELAY 5
- ' b mod TimeStamp fixed. 2019-08-20 twiddled somemore and tested with code above
- d = d + 365 * y ' <<<<<<<<<<<<<<< Steve uses loop number of days before counting leap years
- s~&& = d * 24 * 60 * 60 'Seconds are days * 24 hours * 60 minutes * 60 seconds
- BmodTimeStamp## = (s~&& + t##)
- 'https://www.qb64.org/forum/index.php?topic=1638.msg108566#msg108566
- 'Steve last edit 10:58 AM 2019-08-20
- 'Based on Unix Epoch time, which starts at year 1970.
- 'Minor fixes to leap year logic by Bplus. Many thanks!
- d = d + 365
- 'unless the current year is 2000!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1
- s~&& = d * 24 * 60 * 60 'Seconds are days * 24 hours * 60 minutes * 60 seconds
- TimeStamp## = (s~&& + t##)
The two TimeStamp## functions produce different results:
BmodTimeStamp## has 0 for date 01-01-1970 0 AM, because I subtract 1 from d calculated off Date$, that Day should not count as a full day. Also all the sub variables are DIM and the loop counting Days up is a one liner formula: d = d + 365 * y. I also removed CASE 1: d = d because it wasn't needed.
Steve's TimeStamp## function as of 11 AM this morning is exactly a days worth of seconds more for 01-01-1970 0 AM and I have fixed the same for the 2000 no leap year bug.
I think the BmodTimeStamp## is the more accrate.
Post by: petoro on August 21, 2019, 04:40:02 am
Post by: SMcNeill on August 21, 2019, 04:57:34 am
Code: QB64: [Select]
- ' b mod TimeStamp fixed. 2019-08-20 twiddled somemore and tested with code above
- d = d + 365 * y ' <<<<<<<<<<<<<<< Steve uses loop number of days before counting leap years
- s~&& = d * 24 * 60 * 60 'Seconds are days * 24 hours * 60 minutes * 60 seconds
- BmodTimeStamp## = (s~&& + t##)
- 'Based on Unix Epoch time, which starts at year 1970.
- d = d + 29 'its a leap year
- d = d - 1 'the year is divisible by 100, and not divisible by 400
- ELSE 'year not divisible by 4, no worries
- d = d + 28
- d = (d - 1) + 365 * y 'current month days passed + 365 days per each standard year
- d = d + 1 'add an extra day every leap year
- s~&& = d * 24 * 60 * 60 'Seconds are days * 24 hours * 60 minutes * 60 seconds
- TimeStamp## = (s~&& + t##)
With the original ExtendedTimer on the forums here, I was wondering WHY we got the correct answer, without subtracting a day from our date entry. It's because we were completely handling the leap years wrongly to begin with... The year 2000 *IS* a leap year, so by taking a day off for it (when we shouldn't have), it shifted the answer back a day, giving us the correct time for TODAY...
Which ended up making it one of those glitches which actually fixed another glitch, which ended up giving the proper result when it shouldn't have! Testing it as a TimeStamp, which allows us to flow up and down to any particular date, allowed us to finally showcase the glitch and make adjustments to it.
Unfortunately, by correcting one glitch (subtracting one from the day), you've now left the second glitch to run without correction (the false 2000 leap year subtraction), meaning things are still just as broken as ever!
I'm thinking the above fixes all issues and gets us up to EUT compliance, but test it out for yourself and see what you think. If it passes muster this time around, I'll redo ExtendedTimer to be correct as well, and we'll have STx correct the code in the toolbox.
The toolbox ExtendedTimer gives us the right result just because it's wrong at being wrong! 0_o!!
Post by: SMcNeill on August 21, 2019, 04:59:11 am
In fact 2000 WAS a leap year as usual. It is because it was divisible but 100 BUT ALSO by 400!
I was correcting that as you posted. I think the latest version here takes all those subtle variations into account:
Code: QB64: [Select]
- 'Based on Unix Epoch time, which starts at year 1970.
- d = d + 29 'its a leap year
- d = d - 1 'the year is divisible by 100, and not divisible by 400
- ELSE 'year not divisible by 4, no worries
- d = d + 28
- d = (d - 1) + 365 * y 'current month days passed + 365 days per each standard year
- d = d + 1 'add an extra day every leap year
- s~&& = d * 24 * 60 * 60 'Seconds are days * 24 hours * 60 minutes * 60 seconds
- TimeStamp## = (s~&& + t##)
Post by: SMcNeill on August 21, 2019, 05:41:46 am
DEC 31, 1969, 23:59:59 = -1
DEC 31, 1969, 23:59:58 = -2
... and so on.
With the medications I'm on, I'm surprised I managed to count forward to get to the point where it's currently working properly; I sure don't feel like making it count backwards at the moment. I leave that mod to Bplus, if he feels like adding it, otherwise positive timestamps are good enough for my needs... ;)
Post by: STxAxTIC on August 21, 2019, 06:20:08 am
Post by: bplus on August 21, 2019, 09:09:13 am
In fact 2000 WAS a leap year as usual. It is because it was divisible but 100 BUT ALSO by 400!
Yikes! nothing like wasting allot of time under a false premise.
Well it's not wasted if I learn something positive from it!
Post by: bplus on August 21, 2019, 09:25:14 am
Quote
The toolbox ExtendedTimer gives us the right result just because it's wrong at being wrong! 0_o!!
The toolbox code last edited August 11, 2019 is still flawed when the current month is < 3
Code: QB64: [Select]
Post by: petoro on August 21, 2019, 01:15:01 pm
Yikes! nothing like wasting allot of time under a false premise.
Well it's not wasted if I learn something positive from it!
The western calendar has some twisted details :)
Post by: bplus on August 21, 2019, 01:42:12 pm
The western calendar has some twisted details :)
:)) What's twisted are the Earth's rotations and revolutions.
Post by: SMcNeill on August 22, 2019, 11:18:55 am
Code: QB64: [Select]
- SHELL "https://www.epochconverter.com/"
- PRINT "Compare to time stamps generated at the website which popped up in your browser.https://www.epochconverter.com/"
- INPUT "Give me a DATE$ in format of DD-MM-YYYY"; d$
- INPUT "Give me a TIMER value from 0 to 86399.999"; t##
- 'Based on Unix Epoch time, which starts at year 1970.
- d = d + 1 'assume we had a leap year, subtract another day
- 'then count the months that passed after the current month
- 'we should now have the entered year calculated. Now lets add in for each year from this point to 1970
- d = d + 365 * (1969 - y) '365 days per each standard year
- d = d + 1 'subtract an extra day every leap year
- s## = d * 24 * 60 * 60 'Seconds are days * 24 hours * 60 minutes * 60 seconds
- TimeStamp## = -(s## + 24 * 60 * 60 - t##)
- y = y - 1970
- d = d + 29 'its a leap year
- d = d - 1 'the year is divisible by 100, and not divisible by 400
- ELSE 'year not divisible by 4, no worries
- d = d + 28
- d = (d - 1) + 365 * y 'current month days passed + 365 days per each standard year
- d = d + 1 'add an extra day every leap year
- s## = d * 24 * 60 * 60 'Seconds are days * 24 hours * 60 minutes * 60 seconds
- TimeStamp## = (s## + t##)
- FUNCTION ExtendedTimer##
Post by: bplus on August 22, 2019, 03:24:08 pm
Quote
IF y < 1970 THEN 'calculate shit backwardsNice to extend this back!
Steve, have you considered a timestamp decoder ring? a reverse function to restore date and time.
Also something I've noticed from start:
Code: QB64: [Select]
loose l and l1 variables and use straight MID$ extraction of m, d, y and you loose the restriction of the separator having to be "-" thusly a "/", a space, any single character would work just as well.
Post by: bplus on August 22, 2019, 03:47:43 pm
Steve, you said yourself you use a different system for autosave, one I can appreciate for it's transparency.
Wait... maybe I can for myself, using it to calculate date and time differences. My code that I worked out yesterday was pretty inefficient counting one by one the days until I reach the later date. Converting to seconds, subtracting seconds and then converting to days hours minutes secs.... might be easier or more efficient.
Post by: SMcNeill on August 22, 2019, 04:05:20 pm
Wait... before we spend another second (or I in checking code of this coding exercise), can someone review for me the practical benefits it might serve?
Steve, you said yourself you use a different system for autosave, one I can appreciate for it's transparency.
Wait... maybe I can for myself, using it to calculate date and time differences. My code that I worked out yesterday was pretty inefficient counting one by one the days until I reach the later date. Converting to seconds, subtracting seconds and then converting to days hours minutes secs.... might be easier or more efficient.
I haven’t used it for a time stamp before (which is why there was so many little glitches to work out); what I use all the time is the ExtendedTimer. QB64 has 2 ways we can track time — TIME$ and TIMER. For most usages, I find myself using TIMER a lot more than I would TIME$ (it’s hard to add and subtract hours, minutes, and seconds...), but TIMER has one great flaw...
MIDNIGHT!!
Start a program at 11:59:59 PM (86399 seconds), and wait 10 seconds to do something.... and you’ll wait forever with IF TIMER > StartTime + 10 THEN....
Your timer goes back to 0 at midnight, so you’ll never pass (86409 seconds) — putting your program into an endless loop.
Thus, I added ExtendedTimer. It tracks time with days, months, years, so midnight is no longer an issue. Where “IF TIMER > StartTime + 10 THEN....” fails at midnight, “IF ExtendedTimer > StartTime + 10 THEN...” doesn’t.
Post by: bplus on August 22, 2019, 04:43:47 pm
Extended timer would work if run something more than a day (I don't) and Timer is no good for that kind usage either.
Post by: STxAxTIC on August 24, 2019, 05:48:42 pm
I apologize for not following this thread to a tee, and not doing my proper reading on the tit-for-tat that happened... but can one of you fine gentleman reply to this with what *should* appear in the toolbox? Thanks kindly.
Post by: bplus on August 24, 2019, 06:00:09 pm
Heya boys,
I apologize for not following this thread to a tee, and not doing my proper reading on the tit-for-tat that happened... but can one of you fine gentleman reply to this with what *should* appear in the toolbox? Thanks kindly.
Steve has something very interesting posted in #19 August 22
I have not had a chance to give it a test drive, I did want to check and see how it did calculating time & date differences for my submission for code challenge "Count Down 2020" but then Ken came up with more interesting problem and I got side tracked.
Not that you need my seal of approval, but it would be nice if someone tried to break it before submitting to librarian to save librarian's valuable time spent editing buggy code.
Post by: SMcNeill on August 24, 2019, 06:18:30 pm
Code: QB64: [Select]
- SHELL "https://www.epochconverter.com/"
- PRINT "Compare to time stamps generated at the website which popped up in your browser.https://www.epochconverter.com/"
- _LIMIT 1
- ' If the times seem off from the website, you'll want to change the timezone
- ' offset to match your current time zone.
- PRINT ExtendedTimer 'Unix Epoch Timer based on local time.
- 'Based on Unix Epoch time, which starts at year 1970.
- d = d + 1 'assume we had a leap year, subtract another day
- 'then count the months that passed after the current month
- 'we should now have the entered year calculated. Now lets add in for each year from this point to 1970
- d = d + 365 * (1969 - y) '365 days per each standard year
- d = d + 1 'subtract an extra day every leap year
- s## = d * 24 * 60 * 60 'Seconds are days * 24 hours * 60 minutes * 60 seconds
- TimeStamp## = -(s## + 24 * 60 * 60 - t##)
- y = y - 1970
- d = d + 29 'its a leap year
- d = d - 1 'the year is divisible by 100, and not divisible by 400
- ELSE 'year not divisible by 4, no worries
- d = d + 28
- d = (d - 1) + 365 * y 'current month days passed + 365 days per each standard year
- d = d + 1 'add an extra day every leap year
- s## = d * 24 * 60 * 60 'Seconds are days * 24 hours * 60 minutes * 60 seconds
- TimeStamp## = (s## + t##)
- FUNCTION ExtendedTimer##
- 'Simplified version of the TimeStamp routine, streamlined to only give positive values based on the current timer.
- 'Note: Only good until the year 2100, as we don't do all the fancy calculations for leap years.
- 'A timer should work quickly and efficiently in the background; and the less we do, the less lag we might insert
- 'into a program.
- day = DATE$
- d = (d - 1) + 365 * y 'current month days passed + 365 days per each standard year
- d = d + (y + 2) \ 4 'add in days for leap years passed
- s = d * 24 * 60 * 60 'Seconds are days * 24 hours * 60 minutes * 60 seconds
The demo should speak for itself, I'd hope. ;)
Post by: bplus on August 24, 2019, 09:12:38 pm
I am using this code to calculate difference in dates using your timeStamp## and code I used in my last post in Count Down 2020:
Code: QB64: [Select]
- secLate## = TimeStamp##(LaterDate$, LaterTime##)
- secEarly## = TimeStamp##(EarlierDate$, EarlierTime##)
- secDiff = secLate## - secEarly##
- 'covert to days, hours, minutes, secs I am dropping fraction secs for test
- secDiff = secDiff - days * 86400
- secDiff = secDiff - hours * 3600
The good news we agree for years >=1970, bad news there is difference in days for years earlier than 1970.
This is the completely new section of your timeStamp## code that I thought should be tested because the web site can't verify your numbers in those circumstances.
I am currently revising the test to maybe help see what is off.
Post by: SMcNeill on August 24, 2019, 09:34:12 pm
Times were matching at my last tests, unless I posted a glitchy version on the forums here... I’ll recheck results again to see what’s up.
Post by: bplus on August 24, 2019, 09:51:22 pm
It's the new part of your code where you attempt dates before 1970, here is my test code:
Code: QB64: [Select]
- '2019-08-24 Quick test Steve timestamp by comparing DiffDateTime$ to TimeStampDiff$
- 'I am just testing day counts
- times$ = "00:00:00": times## = 0
- dates$(3) = "08-24-2019": dates$(2) = "01-01-2020": dates$(1) = "01-01-2021": dates$(0) = "01-01-2025"
- dates$(4) = "01-01-2019": dates$(5) = "01-01-1970": dates$(6) = "01-01-1815"
- INPUT "OK ... press enter "; w$
- d1970$ = "01-01-1970"
- PRINT d1970$; " Minus "; d$
- INPUT "OK ... press enter "; w$
- ' I used this code for Count Down 2020
- 'note: this uses 2 dates and times formatted with DateTime$() Function
- ''did we barrow off day
- 'PRINT ly, lmm, ld ' check target and start
- 'PRINT ey, emm, ed
- 'now count days
- ed = ed + 1
- cnt = cnt + 1
- 'is it leap year
- 'pass
- emm = 3: ed = 1
- emm = 3: ed = 1
- emm = emm + 1: ed = 1
- ed = 1: emm = 1: ey = ey + 1
- ed = 1: emm = emm + 1
- 'PRINT ey, emm, ed, ly; " "; lmm; " "; ld 'Check progress
- '_LIMIT 2
- FUNCTION CurrentDateTime$
- CurrentDateTime$ = " - - _ : : "
- DateTime$ = " - - _ : : "
- IsLeapYear = 1
- 'this calc date time diff using Steve' TimeStamp## secs
- secLate## = TimeStamp##(LaterDate$, LaterTime##)
- secEarly## = TimeStamp##(EarlierDate$, EarlierTime##)
- secDiff = secLate## - secEarly##
- 'covert to days, hours, minutes, secs I am dropping fraction secs for test
- secDiff = secDiff - days * 86400
- secDiff = secDiff - hours * 3600
- ' Steve's latest version
- ' https://www.qb64.org/forum/index.php?topic=1638.msg108650#msg108650
- 'Based on Unix Epoch time, which starts at year 1970.
- d = d - 1 'assume we had a leap year, subtract another day
- 'then count the months that passed after the current month
- 'we should now have the entered year calculated. Now lets add in for each year from this point to 1970
- d = d + 365 * (1969 - y) '365 days per each standard year
- d = d + 1 'subtract an extra day every leap year
- s## = d * 24 * 60 * 60 'Seconds are days * 24 hours * 60 minutes * 60 seconds
- TimeStamp## = -(s## + 24 * 60 * 60 - t##)
- y = y - 1970
- d = d + 29 'its a leap year
- d = d - 1 'the year is divisible by 100, and not divisible by 400
- ELSE 'year not divisible by 4, no worries
- d = d + 28
- d = (d - 1) + 365 * y 'current month days passed + 365 days per each standard year
- d = d + 1 'add an extra day every leap year
- s## = d * 24 * 60 * 60 'Seconds are days * 24 hours * 60 minutes * 60 seconds
- TimeStamp## = (s## + t##)
Post by: SMcNeill on August 24, 2019, 10:48:20 pm
Code: QB64: [Select]
- '2019-08-24 Quick test Steve timestamp by comparing DiffDateTime$ to TimeStampDiff$
- 'I am just testing day counts
- times$ = "00:00:00": times## = 0
- dates$(3) = "08-24-2019": dates$(2) = "01-01-2020": dates$(1) = "01-01-2021": dates$(0) = "01-01-2025"
- dates$(4) = "01-01-2019": dates$(5) = "01-01-1970": dates$(6) = "01-01-1815"
- INPUT "OK ... press enter "; w$
- d1970$ = "01-01-1970"
- PRINT d1970$; " Minus "; d$
- INPUT "OK ... press enter "; w$
- ' I used this code for Count Down 2020
- 'note: this uses 2 dates and times formatted with DateTime$() Function
- ''did we barrow off day
- 'PRINT ly, lmm, ld ' check target and start
- 'PRINT ey, emm, ed
- 'now count days
- ed = ed + 1
- cnt = cnt + 1
- 'is it leap year
- 'pass
- emm = 3: ed = 1
- emm = 3: ed = 1
- emm = emm + 1: ed = 1
- ed = 1: emm = 1: ey = ey + 1
- ed = 1: emm = emm + 1
- 'PRINT ey, emm, ed, ly; " "; lmm; " "; ld 'Check progress
- '_LIMIT 2
- FUNCTION CurrentDateTime$
- CurrentDateTime$ = " - - _ : : "
- DateTime$ = " - - _ : : "
- IsLeapYear = 1
- 'this calc date time diff using Steve' TimeStamp## secs
- secLate## = TimeStamp##(LaterDate$, LaterTime##)
- secEarly## = TimeStamp##(EarlierDate$, EarlierTime##)
- secDiff = secLate## - secEarly##
- 'covert to days, hours, minutes, secs I am dropping fraction secs for test
- secDiff = secDiff - days * 86400
- secDiff = secDiff - hours * 3600
- ' Steve's latest version
- ' https://www.qb64.org/forum/index.php?topic=1638.msg108650#msg108650
- 'Based on Unix Epoch time, which starts at year 1970.
- d = d + 1 'assume we had a leap year, subtract another day
- 'then count the months that passed after the current month
- 'we should now have the entered year calculated. Now lets add in for each year from this point to 1970
- d = d + 365 * (1969 - y) '365 days per each standard year
- d = d + 1 'subtract an extra day every leap year
- s## = d * 24 * 60 * 60 'Seconds are days * 24 hours * 60 minutes * 60 seconds
- TimeStamp## = -(s## + 24 * 60 * 60 - t##)
- y = y - 1970
- d = d + 29 'its a leap year
- d = d - 1 'the year is divisible by 100, and not divisible by 400
- ELSE 'year not divisible by 4, no worries
- d = d + 28
- d = (d - 1) + 365 * y 'current month days passed + 365 days per each standard year
- d = d + 1 'add an extra day every leap year
- s## = d * 24 * 60 * 60 'Seconds are days * 24 hours * 60 minutes * 60 seconds
- TimeStamp## = (s## + t##)
According to the website (and screenshot attached), the above is now calculating the dates properly.
All it took was to change the signs in this area to + instead of -:
Code: [Select]
'then count the months that passed after the current month
FOR i = m + 1 TO 12
SELECT CASE i
CASE 2: d = d + 28
CASE 3, 5, 7, 8, 10, 12: d = d + 31
CASE 4, 6, 9, 11: d = d + 30
END SELECT
NEXTNow, how the flip did I manage to post it with the signs reversed? And how the flippy flip did I manage to get it sooo close to working, and yet never catch that the results were completely screwed up? All I can say is, "I'm damn talented!!"
My times are matching the official times, but yours are now off by a day.
Post by: bplus on August 24, 2019, 11:05:47 pm
Post by: SMcNeill on August 24, 2019, 11:09:40 pm
Wow that is way better, but leap years look like they are off 2 days, as if instead of adding one one is subtracted or vice versa...
Stupid sign was reversed on them as well. /sigh.
Got any explanation on how the heck that could happen??
Post by: bplus on August 24, 2019, 11:25:08 pm
Stupid sign was reversed on them as well. /sigh.
Got any explanation on how the heck that could happen??
Your evil twin came in a sabotaged your work?
Meds? seems a pretty intelligent and conscious act for meds but I've heard of people driving when sleep walking.
Enemies with forum personnel? Don't even want to go there...
If this is what happened it is truly weird!!
What kind of books do you write? I was just looking tonight when I read your Repo post. I found a Steve McNeill author of GameOn and Rebirth, that you?
Post by: SMcNeill on August 24, 2019, 11:39:34 pm
What kind of books do you write? I was just looking tonight when I read your Repo post. I found a Steve McNeill author of GameOn and Rebirth, that you?
Those are mine. As well as a ton of stuff over at RoyalRoad, Inkitt, and Goodreads.
https://www.royalroad.com/fictions/search?author=Darkbringer&tagsAdd=fantasy&maxPages=20000&status=HIATUS
https://www.inkitt.com/Darkbringer
(Here's hoping the links above work for you.)
Note -- the links above are the unedited versions which I tend to share for promotional purposes, before they're all polished up nice and neat and then published to earn me a little extra hamburger money. ;)
Post by: bplus on August 25, 2019, 12:40:28 am
Post by: bplus on August 25, 2019, 04:17:24 pm
Here is adjustment to test code that points to the on / off day amounts,
Code: QB64: [Select]
The code I am comparing to arrives at the day amounts the same old way regardless of when the earlier date starts and counts day by day up to the later date. I am pretty sure it's correct no matter the earlier date because it is following the leap year rules and is always going in the same time direction but it's likely to be much slower than Steve's where you just do subtraction of seconds of the 2 time dates and convert the secs to days, hours, minutes... but the 2 time dates do need to be correct of course.
Ah I know check New Years 1899 time## = 0 with link.
Update: took me awhile to figure out 24hr option on preference, got it 1899-01-01:
The difference is exactly 1 days worth of seconds 86400.
Post by: SMcNeill on August 25, 2019, 05:50:56 pm
Here's the fix:
Code: QB64: [Select]
- '2019-08-24 Quick test Steve timestamp by comparing DiffDateTime$ to TimeStampDiff$
- 'I am just testing day counts
- times$ = "00:00:00": times## = 0
- dates$(3) = "08-24-2019": dates$(2) = "01-01-2020": dates$(1) = "01-01-2021": dates$(0) = "01-01-2025"
- dates$(4) = "01-01-2019": dates$(5) = "01-01-1970": dates$(6) = "01-01-1815"
- INPUT "OK ... press enter "; w$
- d1970$ = "01-01-1970"
- PRINT d1970$; " Minus "; d$
- INPUT "OK ... press enter "; w$
- ' I used this code for Count Down 2020
- 'note: this uses 2 dates and times formatted with DateTime$() Function
- ''did we barrow off day
- 'PRINT ly, lmm, ld ' check target and start
- 'PRINT ey, emm, ed
- 'now count days
- ed = ed + 1
- cnt = cnt + 1
- 'is it leap year
- 'pass
- emm = 3: ed = 1
- emm = 3: ed = 1
- emm = emm + 1: ed = 1
- ed = 1: emm = 1: ey = ey + 1
- ed = 1: emm = emm + 1
- 'PRINT ey, emm, ed, ly; " "; lmm; " "; ld 'Check progress
- '_LIMIT 2
- FUNCTION CurrentDateTime$
- CurrentDateTime$ = " - - _ : : "
- DateTime$ = " - - _ : : "
- IsLeapYear = 1
- 'this calc date time diff using Steve' TimeStamp## secs
- secLate## = TimeStamp##(LaterDate$, LaterTime##)
- secEarly## = TimeStamp##(EarlierDate$, EarlierTime##)
- secDiff = secLate## - secEarly##
- 'covert to days, hours, minutes, secs I am dropping fraction secs for test
- secDiff = secDiff - days * 86400
- secDiff = secDiff - hours * 3600
- ' Steve's latest version
- ' https://www.qb64.org/forum/index.php?topic=1638.msg108650#msg108650
- 'Based on Unix Epoch time, which starts at year 1970.
- d = d - 1 'assume we had a leap year, subtract another day
- 'then count the months that passed after the current month
- 'we should now have the entered year calculated. Now lets add in for each year from this point to 1970
- d = d + 365 * (1969 - y) '365 days per each standard year
- d = d + 1 'subtract an extra day every leap year
- s## = d * 24 * 60 * 60 'Seconds are days * 24 hours * 60 minutes * 60 seconds
- TimeStamp## = -(s## + 24 * 60 * 60 - t##)
- y = y - 1970
- d = d + 29 'its a leap year
- d = d - 1 'the year is divisible by 100, and not divisible by 400
- ELSE 'year not divisible by 4, no worries
- d = d + 28
- d = (d - 1) + 365 * y 'current month days passed + 365 days per each standard year
- d = d + 1 'add an extra day every leap year
- s## = d * 24 * 60 * 60 'Seconds are days * 24 hours * 60 minutes * 60 seconds
- TimeStamp## = (s## + t##)
This glitch makes perfect sense to me (unlike the swapped signs):
In the second half of the code (where we count forwards), we see this line -- IF (i MOD 100) = 30 AND (i MOD 400) <> 30 THEN d = d - 1 'but skiping every year divisible by 100, but not 400
And then, it was simply copy/pasted into the top half of the code, as is, which doesn't work.
In the bottom half, we subtract 1970 from our year, and start calculating as if we're working up from year 0. 30 years would be the year 2000. 130 years would be the year 2100... Years mod 100 = 30, are the years we need to check to see if they're leap years or not...
In the top half, we work with the date directly, without subtracting that 1970... 1900 is 1900, not -70... We have to year mod 100 = 0 to check for those special "are they, aren't they" leap years?
A simple change of the remainder in those MOD statements, and all appears to be working correctly. (Of course, I've thought that before, and some edge case always seems to show up to toss that idea upside down on its head...)
Post by: SMcNeill on August 25, 2019, 05:56:09 pm
Code: QB64: [Select]
- SHELL "https://www.epochconverter.com/"
- PRINT "Compare to time stamps generated at the website which popped up in your browser.https://www.epochconverter.com/"
- _LIMIT 1
- ' If the times seem off from the website, you'll want to change the timezone
- ' offset to match your current time zone.
- PRINT ExtendedTimer 'Unix Epoch Timer based on local time.
- 'Based on Unix Epoch time, which starts at year 1970.
- d = d + 1 'assume we had a leap year, subtract another day
- 'then count the months that passed after the current month
- 'we should now have the entered year calculated. Now lets add in for each year from this point to 1970
- d = d + 365 * (1969 - y) '365 days per each standard year
- d = d + 1 'subtract an extra day every leap year
- s## = d * 24 * 60 * 60 'Seconds are days * 24 hours * 60 minutes * 60 seconds
- TimeStamp## = -(s## + 24 * 60 * 60 - t##)
- y = y - 1970
- d = d + 29 'its a leap year
- d = d - 1 'the year is divisible by 100, and not divisible by 400
- ELSE 'year not divisible by 4, no worries
- d = d + 28
- d = (d - 1) + 365 * y 'current month days passed + 365 days per each standard year
- d = d + 1 'add an extra day every leap year
- s## = d * 24 * 60 * 60 'Seconds are days * 24 hours * 60 minutes * 60 seconds
- TimeStamp## = (s## + t##)
- FUNCTION ExtendedTimer##
- 'Simplified version of the TimeStamp routine, streamlined to only give positive values based on the current timer.
- 'Note: Only good until the year 2100, as we don't do all the fancy calculations for leap years.
- 'A timer should work quickly and efficiently in the background; and the less we do, the less lag we might insert
- 'into a program.
- day = DATE$
- d = (d - 1) + 365 * y 'current month days passed + 365 days per each standard year
- d = d + (y + 2) \ 4 'add in days for leap years passed
- s = d * 24 * 60 * 60 'Seconds are days * 24 hours * 60 minutes * 60 seconds
Post by: SMcNeill on December 27, 2019, 04:06:53 am
Code: QB64: [Select]
- FUNCTION ExtendedTimer##
- 'modified extendedtimer to store the old day's count, and not have to recalculate it every time the routine is called.
- day = DATE$
- d = (d - 1) + 365 * y 'current month days passed + 365 days per each standard year
- d = d + (y + 2) \ 4 'add in days for leap years passed
- s = d * 24 * 60 * 60 'Seconds are days * 24 hours * 60 minutes * 60 seconds
- old_day = s
- old_day = s + 83400 'add another worth of seconds to our counter
- oldt = TIMER
- olds = old_day + oldt
- ExtendedTimer## = olds
More efficient version of ExtendedTimer. This stores our day values and only updates them when necessary. We really don't need to figure out how many seconds are in today over and over endlessly -- just count them once, and when the clock swaps back to 0:0:0, add 24*60*60 seconds to the count.
Post by: EricE on March 27, 2020, 09:24:21 pm
Post by: EricE on March 27, 2020, 09:34:33 pm
I have started a new thread requesting that the next release of QB64 have a new function which returns the local Time Zone information.
This would be a very useful addition to the QB64 compiler.
EricE
Post by: zaadstra on September 29, 2021, 04:37:05 pm
I've been running this program (in the green box), and I'm puzzled with the timezone. My TZ offset now is +02:00 but the program only matches the website when I enter: CONST MyTimeZone## = -2 * 3600
The ExtendedTimer output also is wrong and can't be offset so it seems.
I may have found old obsolete abandoned code ... just wondering ... I'm building a compare for these date/times: 2019:04:29 13:23:50 (UTC) and 2019:04:29 15:23:49+02:00 (local time notation) ... so still a long way to go. Normally it would just be subtracting one or two hours (DST) but things get awkward when changing days, month or even year....
Post by: Pete on September 29, 2021, 07:13:30 pm
Pete
Post by: zaadstra on October 03, 2021, 09:54:14 am
I need it to do some tricks with Exiftool so the format is based on that. It is easy to modify.
There is a routine to convert a normal timestamp to UNIX epoch time, and a routine to convert the other way around.
Time to UNIX is based on the POSIX calculation formula, and UNIX to time is based on an academic paper on Julian dates.
I've put a small loop around it to show current time so you can compare it with the website. You need to change the timezone tz= to your region.
Code: QB64: [Select]
- _TITLE "Timestamp and Epoch conversion routines"
- ' Configured as Current Time demo loop
- ' Based on Exiftool 2019:02:05 17:50:30 2019:02:05 18:50:30 +01:00
- tm$ = "2021:10:02 21:00:00"
- 'tm$ = "1970:01:02 00:00:00"
- 'tm$ = "2319:02:05 17:50:30"
- tm$ = GetNow$
- tz = 2 ' Timezone
- ' date time tm$ to UNIX time
- tm_epoch&& = Epoch&&(tm$) - tz * 3600 ' check: https://www.epochconverter.com/
- PRINT "UNIX epoch time :"; tm_epoch&&
- ' UNIX time to date time
- datetime$ = TimeStamp$(tm_epoch&&)
- PRINT "DateTime UTC : "; datetime$
- datetime$ = TimeStamp$(tm_epoch&& + tz * 3600)
- PRINT "DateTime local : "; datetime$; tz$
- SLEEP 1
- ' call with date and time argument, format: "2021:08:09 14:32:14"
- ' call with argument: UNIX epoch time
- R# = (tm_epoch&& / 86400) + 2440587.5 - 1721118.5 - Z&
- G = Z& - .25
- tod = R# * 86400
- hh = tod \ 3600
- mm = (tod - hh * 3600) \ 60
- FUNCTION GetNow$
You may vote for this as 'best answer', LOL !
P.S. thanks to all forummers helping me with insight on variables :-)
Post by: bplus on October 03, 2021, 11:06:43 am
Can yours be used to calculate the difference between 2 dates and times?
Is there a limit to earliest date & time (like start of Gregorian calendar, assuming Gregorian calculations) and future dates like something in year 2050?
Post by: zaadstra on October 03, 2021, 11:36:24 am
@zaadstra
Can yours be used to calculate the difference between 2 dates and times?
Is there a limit to earliest date & time (like start of Gregorian calendar, assuming Gregorian calculations) and future dates like something in year 2050?
I think yes, that's what I intend to use it for. Although my date/times will be in this age, I have tested working on dates from the year 488 to 2521 and the results checked out with the website.
Post by: zaadstra on October 03, 2021, 11:53:27 am
Gregorian calendar was introduced in the year 1582, and Julian calendar was introduced by Julius Caesar in 46 BC. Julian date 0 is in the year -4712.... There has been a lot of hassling with the calendars during the ages. This Julian calculation with a Gregorian sauce on top calculates the current leap years (UNIX to timestamp routine). You might discuss if that is accurate befoure introducing it before 1582, I did not research that.
Wikipedia and other sites have a lot of information.
Post by: zaadstra on October 03, 2021, 05:25:29 pm
Code: QB64: [Select]
- ' call with argument: UNIX epoch time difference - a number of seconds - best called with ABS(val1_epoch&& - val2_epoch&&)
- year&& = tm_epoch&& \ 31536000: tm_epoch&& = tm_epoch&& - year&&
- month&& = tm_epoch&& \ 2678400: tm_epoch&& = tm_epoch&& - month&&
- day&& = tm_epoch&& \ 86400: tod = tm_epoch&& - day&& * 86400
- hh = tod \ 3600
- mm = (tod - hh * 3600) \ 60
This looks like 0000:00:00 00:12:18 for an epoch diff of 738.