Activity for Phos Quartz
-
Phos Quartz modified a comment on discussion General Discussion
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...
-
At first I thought it might be because you omit the 'rise/set' option, but actually mine seems not to require that. Maybe it has to do with your invocation method. (I don't know anything about Windows.)
-
sunriset.cpp 95c95 < if (abs(cost) < 1.0) --- > if (fabs(cost) < 1.0) makefile 12a13 > OBJECTS_ONLY=sunwait.o sunriset.o print.o 18c19 < $(C) $(OBJECTS) -o $@ $(LDFLAGS) --- > $(C) $(OBJECTS_ONLY) -o $@ $(LDFLAGS) sunwait.cpp 37c37 < #if defined __linux__ --- > #if defined __linux__ || defined __APPLE__ 398c398 < #if defined __linux__ --- > #if defined __linux__ || defined __APPLE__ 418c418 < #if defined __linux__ --- > #if defined __linux__ || defined __APPLE__ 480c480 < #if defined __linux__ ---...
-
sunriset.cpp 95c95 < if (abs(cost) < 1.0) --- > if (fabs(cost) < 1.0) makefile 12a13 > OBJECTS_ONLY=sunwait.o sunriset.o print.o 18c19 < $(C) $(OBJECTS) -o $@ $(LDFLAGS) --- > $(C) $(OBJECTS_ONLY) -o $@ $(LDFLAGS) sunwait.cpp 37c37 < #if defined __linux__ --- > #if defined __linux__ || __APPLE__ 398c398 < #if defined __linux__ --- > #if defined __linux__ || __APPLE__ 418c418 < #if defined __linux__ --- > #if defined __linux__ || __APPLE__ 480c480 < #if defined __linux__ --- > #if defined __linux__...
-
Turns out MacPorts knew it was broken but didn't know why. I linked them to this discussion.
-
Hey guys, thank you for this project! It's great! I own a desktop with macOS 10.12, and have installed Sunwait through MacPorts. This was evidently outside your direct intention as the developers, because some of the code is wrapped in #ifdefs that neglect OSX, and it therefore doesn't execute. Because with most inputs this causes no crash, the MacPorts maintainers seem not to have noticed. (I will link them to this discussion too.) Instead all the outputs are nonsense. I got it to compile with only...
-
Hey guys, thank you for this project! It's great! I own a desktop with macOS 10.12, and have installed Sunwait through MacPorts. This was evidently outside your direct intention as the developers, because some of the code is wrapped in #ifdefs that neglect OSX, and it therefore doesn't execute. Because with most inputs this causes no crash, the MacPorts maintainers seem not to have noticed. (I will link them to this discussion too.) Instead all the outputs are nonsense. I got it to compile with only...
1