Phos Quartz

Hello. I found a bug in the code, and I have a 4-line fix. Surface Symptom Two days out of every year in my time zone, on the days when DST switches, sunwait's output is wrong by one hour. The following day it's back to normal. Closer Study The code calculates 2 time stamps, "Now" and "Target;" the latter may be midnight UTC the same day as "Now," or that of a user-specified day. However it fails to account for the possibility that the interval between "Now" and "Target" might span a change in DST,...

Hello. I found a bug in the code, and I have a 4-line fix. Surface Symptom Two days out of every year in my time zone, on the days when DST switches, sunwait's output is wrong by one hour. The following day it's back to normal. Closer Study The code calculates 2 time stamps, "Now" and "Target;" the latter may be midnight UTC the same day as "Now," or that of a user-specified day. However it fails to account for the possibility that the interval between "Now" and "Target" might span a change in DST,...

I know why this doesn't work, but I can't follow the intended logic. I can't find any details on how strftime() obtains the format conversion for %z. Even the author of Sunwait calls this "secret magic" (line 463). The man page says it uses the environment variables TC and LC_TIME, but getenv() returns NULL for these names both before and after the call to mktime(). The reason it fails here is because a struct tm is being used to represent "UTC." This is not entirely possible; the docs show this...

Since I was looking at this problem just as DST was changing, I've just had the rare opportunity to catch another bug associated with this boundary condition: Debug: All output to use local timezone (nogmt). Debug: Now utcTm: Sun Nov 4 01:56:14 2018 GMT Debug: Now localTm: Sat Nov 3 21:56:14 2018 EDT Debug: Now UTC bias (add to GMT to get EDT) hours: -5.000000 I have checked an double-checked both my local and UTC time. I know my UTC offset right now is -4. Count on your fingers and see the given...

Since I was looking at this problem just as DST was changing, I've just had the rare opportunity to catch another bug associated with this boundary condition: Debug: All output to use local timezone (nogmt). Debug: Now utcTm: Sun Nov 4 01:56:14 2018 GMT Debug: Now localTm: Sat Nov 3 21:56:14 2018 EDT Debug: Now UTC bias (add to GMT to get EDT) hours: -5.000000 I have checked an double-checked both my local and UTC time. I know my UTC offset right now is -4. Count on your fingers and see the given...

(All of the above is in reference to version 0.8, btw, not version 0.4 as represented in the SourceForge Git repo accessible from the "Code" tab above.)

Hello. I found a bug in the code, and I have a single-line fix. Surface Symptom Two days out of every year in my time zone, on the days when DST switches, sunwait's output is wrong by one hour. The following day it's back to normal. Closer Study The code calculates 2 time stamps, "Now" and "Target;" the latter may be midnight UTC the same day as "Now," or that of a user-specified day. However it fails to account for the possibility that the interval between "Now" and "Target" might span a change...

Hello. I found a bug in the code, and I have a single-line fix. Surface Symptom Two days out of every year in my time zone, on the days when DST switches, sunwait's output is wrong by one hour. The following day it's back to normal. Closer Study The code calculates 2 time stamps, "Now" and "Target;" the latter may be midnight UTC the same day as "Now," or that of a user-specified day. However it fails to account for the possibility that the interval between "Now" and "Target" might span a change...