09-16-2024, 10:30 AM
(This post was last modified: 09-16-2024, 10:36 AM by TDarcos.
Edit Reason: correction
)
I have fixed the program. The error about $SET MILITARYTIME=1 if you want to use that, was already in the program, and listed here, we were both wrong! I referred to it as $SET MILITARY=1 but you referred to it as $SET MILITARYTIM=1. I'm not nitpicking, I do appreciate how you found my error. Oh hell, I probably am nitpicking.
Speaking of nitpicking, I discovered a minor error. On line 42 of my original program, and line 39 of Steffan-68's corrected version (he drops some blank lines I used, that's a styling opinion), there should be a comma and space following the day, not just a space. That is also fixed, on line 47 of the revised version.
I also forgot to mention another feature of the program, which I'll mention after the listing.
Now the one feature I forgot to mention is on lines 31-36 of my original, lines 29-34 of Stefan-68's correction, and on lines 36-41 of the revised version, you'll notice I reference DATE$ three times. The check of the date string against the current date, and then getting the date and time again if it changed, is a safety feature in the extremely rare, improbable case that it was exactly midnight when the time was captured, and the date just happened to change immediately after. I make sure I protect against any foreseeable error, 'improbable' is not the same as 'impossible,' and I always assume the universe will go after me or my creations at any chance it can get, and this eliminates that chance.
I know, I calculated the speed of a date/time collection, about 30 years ago, and on a typical 4.77 mhz PC running interpreted Basic, it could collect over 2000 pairs in one second and a compiled Turbo Pascal program could do about 6,000, so statistically the probability is about once in 16 years. Today, with PCs over 800 times faster, the chance it could happen is extremely improbable. But again, improbable does not mean impossible.
If a program is using the Windows GetLocalTime function, however, it is atomic, both are collected simultaneously, so in that case it is impossible for the scenario to happen.
Speaking of nitpicking, I discovered a minor error. On line 42 of my original program, and line 39 of Steffan-68's corrected version (he drops some blank lines I used, that's a styling opinion), there should be a comma and space following the day, not just a space. That is also fixed, on line 47 of the revised version.
I also forgot to mention another feature of the program, which I'll mention after the listing.
Code: (Select All)
' Show-Date_and_Time.bas - Day of week computed using Zeller's congruence
' by Paul Robinson <paul@paul-robinson.us>
' September 15, 2024
' Dedicated to the Public Domain
' I'd like to thank user Steffan-68 from the QB64 Phoenix Edition Forums
' for his catching some errors I made
' September 16, 2024
Option _Explicit
Const Program_Version = "1.1" ' In case I have to fix it again...
Dim As String WeekDays(6), Months(12)
WeekDays(0) = "Saturday"
WeekDays(1) = "Sunday"
WeekDays(2) = "Monday"
WeekDays(3) = "Tuesday"
WeekDays(4) = "Wednesday"
WeekDays(5) = "Thursday"
WeekDays(6) = "Friday"
Months(1) = "January"
Months(2) = "February"
Months(3) = "March"
Months(4) = "April"
Months(5) = "May"
Months(6) = "June"
Months(7) = "July"
Months(8) = "August"
Months(9) = "September"
Months(10) = "October"
Months(11) = "November"
Months(12) = "December"
Dim As String CheckDate, CheckTime, AmPm
Dim As Integer Month, Day, Year, Hour, Minute, Second, WD
CheckDate = Date$
CheckTime = Time$
If CheckDate <> Date$ Then ' Midnight rolled over
CheckDate = Date$
CheckTime = Time$
End If
Month = Val(Left$(CheckDate, 2)): Day = Val(Mid$(CheckDate, 4, 2)): Year = Val(Right$(CheckDate, 4)):
Hour = Val(Left$(CheckTime, 2)): Minute = Val(Mid$(CheckTime, 4, 2)): Second = Val(Right$(CheckTime, 2))
WD = DayOfWeek(Month, Day, Year)
' Display date and time, formatted
Print "It is "; WeekDays(WD); ", "; Months(Month); Str$(Day); ","; Year; " at";
$If MILITARYTIME Then
print checktime
$Else
AmPm = " AM"
If Hour > 12 Then
AmPm = " PM"
Hour = Hour - 12
End If
Print Str$(Hour); ":"; Right$("0" + LTrim$(Str$(Minute)), 2); ":"; Right$("0" + LTrim$(Str$(Second)), 2); AmPm
$End If
End
' Returns 0=Saturday, etc.
Function DayOfWeek% (Month%, Day%, Year%)
Dim As Integer I, J, K, D, M, Y
D = Day%: M = Month%: Y = Year%
If M < 3 Then
M = M + 12
Y = Y - 1
End If
K = Y Mod 100
J = Y / 100
DayOfWeek = (D + 13 * (M + 1) / 5 + K + K / 4 + J / 4 + 5 * J) Mod 7
End Function
Now the one feature I forgot to mention is on lines 31-36 of my original, lines 29-34 of Stefan-68's correction, and on lines 36-41 of the revised version, you'll notice I reference DATE$ three times. The check of the date string against the current date, and then getting the date and time again if it changed, is a safety feature in the extremely rare, improbable case that it was exactly midnight when the time was captured, and the date just happened to change immediately after. I make sure I protect against any foreseeable error, 'improbable' is not the same as 'impossible,' and I always assume the universe will go after me or my creations at any chance it can get, and this eliminates that chance.
I know, I calculated the speed of a date/time collection, about 30 years ago, and on a typical 4.77 mhz PC running interpreted Basic, it could collect over 2000 pairs in one second and a compiled Turbo Pascal program could do about 6,000, so statistically the probability is about once in 16 years. Today, with PCs over 800 times faster, the chance it could happen is extremely improbable. But again, improbable does not mean impossible.
If a program is using the Windows GetLocalTime function, however, it is atomic, both are collected simultaneously, so in that case it is impossible for the scenario to happen.
While 1
Fix Bugs
report all bugs fixed
receive bug report
end while
Fix Bugs
report all bugs fixed
receive bug report
end while