vBCms Comments
Welcome To Hunting Country
General Hunting Forums
Archery & Bowhunting
Shooting Sports
Manufacturers' Corner
Firearms
Classifieds
Not Hunting / General Chit Chat
1.) Swamp Fox - 12/03/2013
Some of my trail cams show one time when you view the picture and a different time one hour later or sooner (I can't remember which just now) when you go to find the picture out of the "Info" or "Details" list.
I am running two different brands of cameras and I think it's just one brand doing it, but I could be wrong. I'd also have to do some investigating to see if it's all the cameras of that brand or if it's just a few specimens. I can grab a couple of the cameras later this afternoon if anyone needs me to be more specific, but the majority of them are deployed right now.
BTW, the cameras are all set for EDST and stay that way throughout the year. Is it possible that the computer reads something on the SD card and changes info in the "Info" file (now that we are on EST) but does not change the time on the picture itself?
This is not something new; I'm just getting around to asking about it, and figured before I attempted to spend a lot of time with tech support....LOL...
I am running two different brands of cameras and I think it's just one brand doing it, but I could be wrong. I'd also have to do some investigating to see if it's all the cameras of that brand or if it's just a few specimens. I can grab a couple of the cameras later this afternoon if anyone needs me to be more specific, but the majority of them are deployed right now.
BTW, the cameras are all set for EDST and stay that way throughout the year. Is it possible that the computer reads something on the SD card and changes info in the "Info" file (now that we are on EST) but does not change the time on the picture itself?
This is not something new; I'm just getting around to asking about it, and figured before I attempted to spend a lot of time with tech support....LOL...
2.) Ventilator - 12/03/2013
WHen you gonna kill one of them deer on your camera? Seems like our team needs your help! :)
3.) Swamp Fox - 12/03/2013
That's a good question.
So far, I'm having a miracle season...It sucks and blows at the same time.
Long story. Lots of moving parts...:bang:
So far, I'm having a miracle season...It sucks and blows at the same time.
Long story. Lots of moving parts...:bang:
4.) DParker - 12/03/2013
Since the difference between the two displayed times is consistently one hour the most likely (though not only) candidate is the trail cam's software adjusting for DST in one case but not the other. That would be a bug. What make and model have you noticed it on? Also, did you notice this behavior also occurring before the switch from EDST to EST?
Also...when did you set the cam clock's time? During when DST was in effect, or when Standard Time was in effect?
Also...when did you set the cam clock's time? During when DST was in effect, or when Standard Time was in effect?
5.) Swamp Fox - 12/03/2013
I'd have to double-check which brand is doing it, or if both are. My cameras are either Wildgame Innovations (90% X6C's) or Bushnell Trophy Cams (80% Cabela's, 20% Bone Collectors).
I've noticed this bug every year, but can't tell you if it's a pre- or just post-DST issue.
I can probably figure out the answers to these questions later tonight, as I go through a few more cards.
Assuming no battery changes (85% reliability for that assumption) the cam clocks get set during DST and I do not reset them when we go to standard time. Any new camera set-ups are put on DST as well, even if Standard time is in effect at that point. That way I can know all cameras are showing me DST's and all I have to remember is the date of the time change, not which camera was set to which time. Most cameras stay out for 6 or 8 months at a time, so it would be a nightmare using two different time standards.
I've noticed this bug every year, but can't tell you if it's a pre- or just post-DST issue.
I can probably figure out the answers to these questions later tonight, as I go through a few more cards.
Assuming no battery changes (85% reliability for that assumption) the cam clocks get set during DST and I do not reset them when we go to standard time. Any new camera set-ups are put on DST as well, even if Standard time is in effect at that point. That way I can know all cameras are showing me DST's and all I have to remember is the date of the time change, not which camera was set to which time. Most cameras stay out for 6 or 8 months at a time, so it would be a nightmare using two different time standards.
6.) luv2bowhunt - 12/03/2013
Man, this explains why you're always in the stands an hour later than you should have been. It's all the cameras fault.:tu:
I would guess the same as DParker, although you've ignited some curiosity in me about my own cameras. I've never noticed that, but I will pay attention to it from now on.
Although I have noticed a glitch in one of my Bushnell HD's, the newer one. Whenever you turn the camera to the off position to remove the SD card, all the settings go back to default. Time, date, everything. Man I hate that.:td:
I would guess the same as DParker, although you've ignited some curiosity in me about my own cameras. I've never noticed that, but I will pay attention to it from now on.
Although I have noticed a glitch in one of my Bushnell HD's, the newer one. Whenever you turn the camera to the off position to remove the SD card, all the settings go back to default. Time, date, everything. Man I hate that.:td:
7.) Swamp Fox - 12/03/2013
You shouldn't lose settings just because of on/off.
I can see time and date going to default if you remove the batteries (although I thought they had an internal battery that would hold those for at least a little while), but my Bushnells don't lose my other settings just because of on/off.
I'll let you know if I see my time and dates going bye-bye at battery change (w. short down time), but I know I don't have the problem w. on/off and no battery change.
Call Bushnell and see if you can get a replacement. 2-year warranty. They often upgrade the camera as well.
Need more info, I can tell you all about Bushnell camera CS...Mostly :tu::tu::tu:
I can see time and date going to default if you remove the batteries (although I thought they had an internal battery that would hold those for at least a little while), but my Bushnells don't lose my other settings just because of on/off.
I'll let you know if I see my time and dates going bye-bye at battery change (w. short down time), but I know I don't have the problem w. on/off and no battery change.
Call Bushnell and see if you can get a replacement. 2-year warranty. They often upgrade the camera as well.
Need more info, I can tell you all about Bushnell camera CS...Mostly :tu::tu::tu:
8.) luv2bowhunt - 12/03/2013
Trust me, I move the switch down to off, pull out the card, put a new card in or copy the pics from the card, turn the switch to setup and the time and date are gone.
Every single time. It's driving me nuts.
Every single time. It's driving me nuts.
9.) billy b - 12/03/2013
He didn't save the settings in the first place most likely.
10.) Swamp Fox - 12/03/2013
You might be right. On my Bushnells, you are supposed to mash "OK" before you move on, and it is possible to move on without realizing you didn't do that.
11.) DParker - 12/03/2013
[QUOTE=Swamp Fox;13080]Assuming no battery changes (85% reliability for that assumption) the cam clocks get set during DST and I do not reset them when we go to standard time. Any new camera set-ups are put on DST as well, even if Standard time is in effect at that point. That way I can know all cameras are showing me DST's and all I have to remember is the date of the time change, not which camera was set to which time. Most cameras stay out for 6 or 8 months at a time, so it would be a nightmare using two different time standards.[/QUOTE]
Assuming that your cameras automatically adjust for DST (almost all computer clocks do these days) then the better solution is to set them for whatever the current time (and date...make sure you set that correctly!) is per the currently active rule (Daylight Saving vs Standard time). The clock should then take care of automatically adjusting itself when the time standard changes, and you're always on the same standard no matter what. If they [I]don't[/I] auto-adjust for DST then, yeah...there's not much else you can do except what you're doing now.
But I'm having a hard time finding any info on what the leading game cameras do (if anything) when it comes to DST.
Assuming that your cameras automatically adjust for DST (almost all computer clocks do these days) then the better solution is to set them for whatever the current time (and date...make sure you set that correctly!) is per the currently active rule (Daylight Saving vs Standard time). The clock should then take care of automatically adjusting itself when the time standard changes, and you're always on the same standard no matter what. If they [I]don't[/I] auto-adjust for DST then, yeah...there's not much else you can do except what you're doing now.
But I'm having a hard time finding any info on what the leading game cameras do (if anything) when it comes to DST.
12.) Swamp Fox - 12/03/2013
Zoinks!
I never even thought about the damn cameras changing the time for me automatically! (Although I don't recall ever opening a camera and seeing that the displayed time was not the same as what I expected, i.e. corresponding to the original method of set-up. I'll have to pay closer attention to be absolutely positive.)
On one level, I can see that being a possible explanation for discrepancy.
[B]But why would the picture say one time and the Details say a different time?[/B]
I think there are a few cameras that went out /got set up after the time change. I guess I'll have to compare them to the ones that have been out longer and see if there's a difference.
I never even thought about the damn cameras changing the time for me automatically! (Although I don't recall ever opening a camera and seeing that the displayed time was not the same as what I expected, i.e. corresponding to the original method of set-up. I'll have to pay closer attention to be absolutely positive.)
On one level, I can see that being a possible explanation for discrepancy.
[B]But why would the picture say one time and the Details say a different time?[/B]
I think there are a few cameras that went out /got set up after the time change. I guess I'll have to compare them to the ones that have been out longer and see if there's a difference.
13.) Swamp Fox - 12/03/2013
I guess it's possible that you set the camera up for one time but any internal/external battery reads the date and stamps the file with the "actual" time...So your file is always right but your picture stamp is always subject to operator whim or error.
But something tells me any internal or external battery/memory (assuming it exists in the first place) isn't that long-lived or sophisticated.
But something tells me any internal or external battery/memory (assuming it exists in the first place) isn't that long-lived or sophisticated.
14.) DParker - 12/03/2013
[QUOTE=Swamp Fox;13101][B]But why would the picture say one time and the Details say a different time?[/B] [/QUOTE]
Most computer clocks track time internally according to Standard Time (either Local or Universal), and don't actually change their internal time when DST goes into/out of effect. Instead, the software that presents the time for display adds a one-hour adjustment (assuming the clock's internal standard is Local time...or else whatever your location's UTC (Universal Time Coordinated) offset if UTC is its internal standard) when displaying a particular date-and-time that occurs during DST, but no such adjustment when displaying one that occurs outside of DST. Similarly, when accepting input (say, when you're setting the time) the software will subtract an hour when translating your input before applying the setting to the internal clock.
So, it may be that the software code that displays the photo is correctly adjusting the internal time for display, while the code that displays the "info" time does not...or vice-versa.
Formal, standardized time reckoning is a much more complicated business than most people realize.
[QUOTE=Swamp Fox;13102]I guess it's possible that you set the camera up for one time but any internal/external battery reads the date and stamps the file with the "actual" time...So your file is always right but your picture stamp is always subject to operator whim or error.
But something tells me any internal or external battery/memory (assuming it exists in the first place) isn't that long-lived or sophisticated.[/QUOTE]
The latter is correct. Batteries don't do anything other than supply electrical energy.
Most computer clocks track time internally according to Standard Time (either Local or Universal), and don't actually change their internal time when DST goes into/out of effect. Instead, the software that presents the time for display adds a one-hour adjustment (assuming the clock's internal standard is Local time...or else whatever your location's UTC (Universal Time Coordinated) offset if UTC is its internal standard) when displaying a particular date-and-time that occurs during DST, but no such adjustment when displaying one that occurs outside of DST. Similarly, when accepting input (say, when you're setting the time) the software will subtract an hour when translating your input before applying the setting to the internal clock.
So, it may be that the software code that displays the photo is correctly adjusting the internal time for display, while the code that displays the "info" time does not...or vice-versa.
Formal, standardized time reckoning is a much more complicated business than most people realize.
[QUOTE=Swamp Fox;13102]I guess it's possible that you set the camera up for one time but any internal/external battery reads the date and stamps the file with the "actual" time...So your file is always right but your picture stamp is always subject to operator whim or error.
But something tells me any internal or external battery/memory (assuming it exists in the first place) isn't that long-lived or sophisticated.[/QUOTE]
The latter is correct. Batteries don't do anything other than supply electrical energy.
15.) Swamp Fox - 12/03/2013
Thanks. That makes some sense.
They could use you over at Healthcaredotguv...
:wink
I guess next year I'll set everything to current time and see if my DST cameras adjust and my post-DST cameras give me synched time stamps.
Maybe I outfoxed myself trying to keep everything on DST regardless of when the camera went out or got a battery change.
They could use you over at Healthcaredotguv...
:wink
I guess next year I'll set everything to current time and see if my DST cameras adjust and my post-DST cameras give me synched time stamps.
Maybe I outfoxed myself trying to keep everything on DST regardless of when the camera went out or got a battery change.
16.) DParker - 12/03/2013
Just be glad we're not talking about GPS so we don't have to go all Einsteinian-special-relativity up in here. :-)
17.) Swamp Fox - 12/04/2013
This place doesn't have coordinates...
After the deer clear the plot, there's nothing left to see, unless you like watching oats and clover grow. I just don't know how to edit the video down.
[video=youtube;6qbs_RP5cOM]http://www.youtube.com/watch?v=6qbs_RP5cOM&feature=youtu.be[/video]
After the deer clear the plot, there's nothing left to see, unless you like watching oats and clover grow. I just don't know how to edit the video down.
[video=youtube;6qbs_RP5cOM]http://www.youtube.com/watch?v=6qbs_RP5cOM&feature=youtu.be[/video]
18.) DParker - 12/04/2013
"This video is private."
Tease.
Tease.
19.) Swamp Fox - 12/04/2013
If you could slow the video down or do a frame-by-frame, you'd be able to see the big buck in that group, LOL.
Oh well. :cf:
Oh well. :cf:
20.) Swamp Fox - 12/04/2013
I can see it embedded on here. Let me know if it's just me.
21.) DParker - 12/04/2013
I see it embedded too. But when I try to play it the opening image is replaced with a black screen and the "This video is private." message. You can see it because you're logged on to your YouTube account on your PC. You need to change the settings for the video to make it publicly viewable.
22.) Ohbuckhunter - 12/04/2013
Dang kids
23.) Swamp Fox - 12/04/2013
I changed it to "Unlisted." See if that works.
24.) Swamp Fox - 12/04/2013
[QUOTE=Ohbuckhunter;13123]Dang kids[/QUOTE]
LOL...
LOL...
25.) Ohbuckhunter - 12/04/2013
Windows movie maker is free and you can edit length of video and slow it down where you want as well.
26.) Ohbuckhunter - 12/04/2013
But yes it works now for us nobodies.
27.) Swamp Fox - 12/04/2013
[QUOTE=Ohbuckhunter;13126]Windows movie maker is free and you can edit length of video and slow it down where you want as well.[/QUOTE]
Can you step it frame by frame?
Can you step it frame by frame?
28.) Swamp Fox - 12/04/2013
Well, I guess you still have to upload it to something like youtube, which means you lose your frame-by-frame capability there, unless somehow you edited it in in the first place.
Am I on the right track?
If I could find a way to let people see PW video the way I'm able to control it at home, that would be cool.
I guess it's too much to ask to share zoom capability.
Am I on the right track?
If I could find a way to let people see PW video the way I'm able to control it at home, that would be cool.
I guess it's too much to ask to share zoom capability.
29.) Swamp Fox - 12/04/2013
[ATTACH=CONFIG]307[/ATTACH]
This is a DST pic....It was taken at 3:07 PM but is listed in the Details list as 4:07.
:bang:
This is a DST pic....It was taken at 3:07 PM but is listed in the Details list as 4:07.
:bang:
30.) Ohbuckhunter - 12/04/2013
You can edit it frame by frame than re upload the video. Takes a lil bit to get use to it. But hey I can even use it so it must be easy.
31.) Swamp Fox - 12/04/2013
Thanks! I'll give it a try in my spare time, LOL.
32.) Ohbuckhunter - 12/04/2013
That will be next year sometime.
33.) DParker - 12/04/2013
[QUOTE=Swamp Fox;13131][ATTACH=CONFIG]307[/ATTACH]
This is a DST pic....It was taken at 3:07 PM but is listed in the Details list as 4:07.[/quote]
So then that probably was 4:07pm. But since you set the time during DST the internal clock's time would be 3:07 (Local Standard Time), and the timestamp in the photo view is not adjusted for DST, while the one in the Details list is.
To test this hypothesis you'll need a photo that was taken after the return to Standard Time, when no DST adjustments should be made in either view. If the time on that photo matches the associated Details list time then we've found the problem (and the time shown will be an hour later than the true time.) If they're still an hour apart then something else is going on.
This is a DST pic....It was taken at 3:07 PM but is listed in the Details list as 4:07.[/quote]
So then that probably was 4:07pm. But since you set the time during DST the internal clock's time would be 3:07 (Local Standard Time), and the timestamp in the photo view is not adjusted for DST, while the one in the Details list is.
To test this hypothesis you'll need a photo that was taken after the return to Standard Time, when no DST adjustments should be made in either view. If the time on that photo matches the associated Details list time then we've found the problem (and the time shown will be an hour later than the true time.) If they're still an hour apart then something else is going on.
34.) Swamp Fox - 12/04/2013
Okay. I just checked a different WG camera ([COLOR="#FF0000"]different [/COLOR] model) set up during Standard time. I set the camera using the DST time (or I assume I did, since that has been my MO). Meaning if it was 1PM when I set the camera, I told the camera it was 2PM. (Or I should have. Hopefully I didn't set it to noon by mistake. I make mistakes more and more these days, LOL.)
On this camera, the time stamp on the pictures matches the time stamp in the Details list.
On this camera, the time stamp on the pictures matches the time stamp in the Details list.
35.) Swamp Fox - 12/04/2013
[QUOTE=DParker;13135]So then that probably was 4:07pm. But since you set the time during DST the internal clock's time would be 3:07 (Local Standard Time), and the timestamp in the photo view is not adjusted for DST, while the one in the Details list is.
To test this hypothesis you'll need a photo that was taken after the return to Standard Time, when no DST adjustments should be made in either view. If the time on that photo matches the associated Details list time then we've found the problem (and the time shown will be an hour later than the true time.) If they're still an hour apart then something else is going on.[/QUOTE]
So that means we're talking about three different times here? A stamp time, a camera time and a Details time?
My head is starting to hurt. I just wanna know which time is right when I'm looking at a picture. :bang:
To test this hypothesis you'll need a photo that was taken after the return to Standard Time, when no DST adjustments should be made in either view. If the time on that photo matches the associated Details list time then we've found the problem (and the time shown will be an hour later than the true time.) If they're still an hour apart then something else is going on.[/QUOTE]
So that means we're talking about three different times here? A stamp time, a camera time and a Details time?
My head is starting to hurt. I just wanna know which time is right when I'm looking at a picture. :bang:
36.) DParker - 12/04/2013
[QUOTE=Swamp Fox;13137]On this camera, the time stamp on the pictures matches the time stamp in the Details list.[/QUOTE]
Was the picture taken when DST was in effect? If so, the camera does not suffer from the same problem. if not, we don't know if it has the problem or not (all times will appear the same when Standard Time is in effect whether the camera has the problem in question or not).
[QUOTE=Swamp Fox;13138]So that means we're talking about three different times here? A stamp time, a camera time and a Details time?[/QUOTE]
No, only 2 different times, at most. The internal clock's time (which represents Standard Time) and, if DST is in effect, the internal clock's time with 1 hour added to it to represent DST. The question then becomes, "Which of these times is being displayed under which circumstances?" In the offending camera's case I'm guessing that the time shown on the image display is the clock's unadjusted time, even when it should be adjusted for DST, while the time shown in the Details display is the clock's time properly adjusted for DST...assuming DST was in effect when the photo was taken.
So to evaluate all this you need to know the date each pic was taken so you know whether or not DST adjustment was [I]supposed[/I] to happen.
Oh, and...stop lying to your cameras about what time it is. :wink
Was the picture taken when DST was in effect? If so, the camera does not suffer from the same problem. if not, we don't know if it has the problem or not (all times will appear the same when Standard Time is in effect whether the camera has the problem in question or not).
[QUOTE=Swamp Fox;13138]So that means we're talking about three different times here? A stamp time, a camera time and a Details time?[/QUOTE]
No, only 2 different times, at most. The internal clock's time (which represents Standard Time) and, if DST is in effect, the internal clock's time with 1 hour added to it to represent DST. The question then becomes, "Which of these times is being displayed under which circumstances?" In the offending camera's case I'm guessing that the time shown on the image display is the clock's unadjusted time, even when it should be adjusted for DST, while the time shown in the Details display is the clock's time properly adjusted for DST...assuming DST was in effect when the photo was taken.
So to evaluate all this you need to know the date each pic was taken so you know whether or not DST adjustment was [I]supposed[/I] to happen.
Oh, and...stop lying to your cameras about what time it is. :wink
37.) Swamp Fox - 12/04/2013
[QUOTE=DParker;13139]Was the picture taken when DST was in effect? If so, the camera does not suffer from the same problem. if not, we don't know if it has the problem or not (all times will appear the same when Standard Time is in effect whether the camera has the problem in question or not).
[/QUOTE]
[QUOTE=Swamp Fox;13137]Okay. [COLOR="#FF0000"]I just checked a different WG camera ([COLOR="#FF0000"]different [/COLOR] model) set up during Standard time.[/COLOR] I set the camera using the DST time (or I assume I did, since that has been my MO). Meaning if it was 1PM when I set the camera, I told the camera it was 2PM. (Or I should have. Hopefully I didn't set it to noon by mistake. I make mistakes more and more these days, LOL.)
[COLOR="#FF0000"]On this camera, the time stamp on the pictures matches the time stamp in the Details list[/COLOR].[/QUOTE]
If I understand your question, the answer is in the highlighted text.
Give me a few minutes to wrap my tiny little head around the rest of your post and I'll be back. :wave:
[/QUOTE]
[QUOTE=Swamp Fox;13137]Okay. [COLOR="#FF0000"]I just checked a different WG camera ([COLOR="#FF0000"]different [/COLOR] model) set up during Standard time.[/COLOR] I set the camera using the DST time (or I assume I did, since that has been my MO). Meaning if it was 1PM when I set the camera, I told the camera it was 2PM. (Or I should have. Hopefully I didn't set it to noon by mistake. I make mistakes more and more these days, LOL.)
[COLOR="#FF0000"]On this camera, the time stamp on the pictures matches the time stamp in the Details list[/COLOR].[/QUOTE]
If I understand your question, the answer is in the highlighted text.
Give me a few minutes to wrap my tiny little head around the rest of your post and I'll be back. :wave:
38.) Swamp Fox - 12/04/2013
Okay, So far we have Camera One, set and taking pictures during DST. The time stamp on the pictures is one hour earlier than the time listed in Details.
Camera Two (unfortunately a different model from the same manufacturer) was set and is taking pictures during Standard time. However, the camera's clock was likely set (on purpose) to DST, one hour later than Local Standard Time. On this camera, taking pictures during Standard Time, the time stamps on the pictures and the times listed in Details match.
Camera Two (unfortunately a different model from the same manufacturer) was set and is taking pictures during Standard time. However, the camera's clock was likely set (on purpose) to DST, one hour later than Local Standard Time. On this camera, taking pictures during Standard Time, the time stamps on the pictures and the times listed in Details match.
39.) Swamp Fox - 12/04/2013
[QUOTE=DParker;13139]
So to evaluate all this you need to know the date each pic was taken so you know whether or not DST adjustment was [I]supposed[/I] to happen.
Oh, and...stop lying to your cameras about what time it is. :wink[/QUOTE]
Fortunately, I think I still have some unerased cards that have pics taken during both time standards. Let me grab some more coffee...
It's hard for me to believe that a manufacturer would DESIGN a camera whose time stamp would not always reflect the time the hunter programmed himself, but I think that's the implication of what you're saying.
So to evaluate all this you need to know the date each pic was taken so you know whether or not DST adjustment was [I]supposed[/I] to happen.
Oh, and...stop lying to your cameras about what time it is. :wink[/QUOTE]
Fortunately, I think I still have some unerased cards that have pics taken during both time standards. Let me grab some more coffee...
It's hard for me to believe that a manufacturer would DESIGN a camera whose time stamp would not always reflect the time the hunter programmed himself, but I think that's the implication of what you're saying.
40.) DParker - 12/04/2013
[QUOTE=Swamp Fox;13145]If I understand your question, the answer is in the highlighted text.[/QUOTE]
Well, the hilighted text is a good clue, but I didn't want to just assume that the camera wasn't setup until [I]after[/I] Spring rather than before it.
[QUOTE=Swamp Fox;13147]It's hard for me to believe that a manufacturer would DESIGN a camera whose time stamp would not always reflect the time the hunter programmed himself, but I think that's the implication of what you're saying.[/QUOTE]
It is reflecting the time you programmed. It's just that the interpretation and representation of time is subject to change based on standards established by political entities, and the camera is, like nearly all computerized devices, attempting to conform to those standards. It just appears to be failing to apply one of those standards in one instance, which is most likely an implementation oversight (bug), not a design choice.
Well, the hilighted text is a good clue, but I didn't want to just assume that the camera wasn't setup until [I]after[/I] Spring rather than before it.
[QUOTE=Swamp Fox;13147]It's hard for me to believe that a manufacturer would DESIGN a camera whose time stamp would not always reflect the time the hunter programmed himself, but I think that's the implication of what you're saying.[/QUOTE]
It is reflecting the time you programmed. It's just that the interpretation and representation of time is subject to change based on standards established by political entities, and the camera is, like nearly all computerized devices, attempting to conform to those standards. It just appears to be failing to apply one of those standards in one instance, which is most likely an implementation oversight (bug), not a design choice.
41.) Swamp Fox - 12/04/2013
Threads like this really test my reading comprehension skills, plus I have a short little span of attention, to quote Paul Simon. This clock, that clock, who's adjusting what, software, operator ...Too much for my little pea brain.
I don't know why, but I just assumed that if I plugged a certain time into the damn camera, that was the time I was gonna see...both on time stamps and in Details. But that would be too easy, LOL.
What I'm getting so far---[B]and please straighten me out if I'm wrong, before I go too far down the rabbit hole and my head explodes[/B]---is that my time stamps on images correspond to the time I input to the camera, but Details is adding an hour during Daylight Savings Time (for some reason) and is not adding that hour during Standard Time.
I don't know why, but I just assumed that if I plugged a certain time into the damn camera, that was the time I was gonna see...both on time stamps and in Details. But that would be too easy, LOL.
What I'm getting so far---[B]and please straighten me out if I'm wrong, before I go too far down the rabbit hole and my head explodes[/B]---is that my time stamps on images correspond to the time I input to the camera, but Details is adding an hour during Daylight Savings Time (for some reason) and is not adding that hour during Standard Time.
42.) bluecat - 12/04/2013
Had to go back to the archives for this one.
43.) Swamp Fox - 12/04/2013
LOL...
I'm afraid to ask why Details would ADD an hour during DST...At the risk of exposing some lack of intelligence on my part, let me ask: Shouldn't it SUBTRACT an hour, if it's going to be all fancy and programmed at all?
We've already sprung forward during DST (and DST is what I'm inputting to the camera), and Details wants to spring forward ANOTHER hour? (But only during DST, not during Standard Time.) :cf:
I'm afraid to ask why Details would ADD an hour during DST...At the risk of exposing some lack of intelligence on my part, let me ask: Shouldn't it SUBTRACT an hour, if it's going to be all fancy and programmed at all?
We've already sprung forward during DST (and DST is what I'm inputting to the camera), and Details wants to spring forward ANOTHER hour? (But only during DST, not during Standard Time.) :cf:
44.) Swamp Fox - 12/04/2013
I just checked a card from a Bushnell. It also adds an hour in the Details list during DST. I'm not sure I have a Bushnell card with Standard Time pics handy.
45.) DParker - 12/04/2013
[QUOTE=Swamp Fox;13154]LOL...
I'm afraid to ask why Details would ADD an hour during DST...At the risk of exposing some lack of intelligence on my part, let me ask: Shouldn't it SUBTRACT an hour, if it's going to be all fancy and programmed at all?
We've already sprung forward during DST (and DST is what I'm inputting to the camera), and Details wants to spring forward ANOTHER hour? (But only during DST, not during Standard Time.) :cf:[/QUOTE]
Well, ponder this, which is based on some assumptions on my part about what the camera manufacturers have likely done...
You've entered some time value into the camera's settings that you're telling it is the current time. If you've done that during the ST (Standard Time) period for all U.S. time zones, which is based on the current date that you've also provided to it, then it will use that exact time to set it's internal clock, because LST (Local Standard Time, whatever your "local" is) is it's internal standard. But if you've set the time during the DST (Daylight Saving Time) period for U.S. time zones, it will subtract an hour from what you entered in order to derive the LST equivalent because, again, that's the clock's internal standard. From that point, all timestamps provided by the clock will represent Standard Time, regardless of whether or not DST is currently in effect. This internal consistency keeps things like time math (for instance, determining how much time has elapsed between two different date-times) simple and efficient. Most systems will also store this unadjusted internal time whenever a timestamp is captured because it can be adjusted for display later, and the aforementioned time math remains easy and straight-forward.
So, when it comes time to display some time provided by the clock the software must first determine whether or not the time being displayed occurred during ST or DST time (again, based on the date when the timestamp was captured). If that time occurred during ST then no adjustment is made, because the timestamp stored already corresponds to that standard. But, if the timestamp was captured during DST then the software must adjust it by [I]adding[/I] 1 hour because, as you noted, DST means that you "spring forward" relative to ST, and the timestamp is always in ST form regardless of when it was captured.
Making sense yet?
Additional question: When setting the camera's time, does it have an option for specifying what time zone you're in (Eastern, Central, Mountain, Pacific, etc)?
I'm afraid to ask why Details would ADD an hour during DST...At the risk of exposing some lack of intelligence on my part, let me ask: Shouldn't it SUBTRACT an hour, if it's going to be all fancy and programmed at all?
We've already sprung forward during DST (and DST is what I'm inputting to the camera), and Details wants to spring forward ANOTHER hour? (But only during DST, not during Standard Time.) :cf:[/QUOTE]
Well, ponder this, which is based on some assumptions on my part about what the camera manufacturers have likely done...
You've entered some time value into the camera's settings that you're telling it is the current time. If you've done that during the ST (Standard Time) period for all U.S. time zones, which is based on the current date that you've also provided to it, then it will use that exact time to set it's internal clock, because LST (Local Standard Time, whatever your "local" is) is it's internal standard. But if you've set the time during the DST (Daylight Saving Time) period for U.S. time zones, it will subtract an hour from what you entered in order to derive the LST equivalent because, again, that's the clock's internal standard. From that point, all timestamps provided by the clock will represent Standard Time, regardless of whether or not DST is currently in effect. This internal consistency keeps things like time math (for instance, determining how much time has elapsed between two different date-times) simple and efficient. Most systems will also store this unadjusted internal time whenever a timestamp is captured because it can be adjusted for display later, and the aforementioned time math remains easy and straight-forward.
So, when it comes time to display some time provided by the clock the software must first determine whether or not the time being displayed occurred during ST or DST time (again, based on the date when the timestamp was captured). If that time occurred during ST then no adjustment is made, because the timestamp stored already corresponds to that standard. But, if the timestamp was captured during DST then the software must adjust it by [I]adding[/I] 1 hour because, as you noted, DST means that you "spring forward" relative to ST, and the timestamp is always in ST form regardless of when it was captured.
Making sense yet?
Additional question: When setting the camera's time, does it have an option for specifying what time zone you're in (Eastern, Central, Mountain, Pacific, etc)?
46.) bluecat - 12/04/2013
We recently "fell back" on November 2. We are not on DST currently. We are in standard time.
47.) DParker - 12/04/2013
[QUOTE=bluecat;13162]We recently "fell back" on November 2. We are not on DST currently. We are in standard time.[/QUOTE]
And I'm assuming things are actually simpler than they might be, depending on Swampy's answer to my last question. If the the camera allows you to tell it what time zone you're in there's a possibility that it's actually doing what most computer systems do. Namely, tracking and storing time according to UTC (Universal Time Coordinated...which is [I]almost[/I] the same as GMT - Greenwich Mean Time) and then adjusting that time for display based on the time zone you're in plus whatever DST adjustment is required, if any.
And I'm assuming things are actually simpler than they might be, depending on Swampy's answer to my last question. If the the camera allows you to tell it what time zone you're in there's a possibility that it's actually doing what most computer systems do. Namely, tracking and storing time according to UTC (Universal Time Coordinated...which is [I]almost[/I] the same as GMT - Greenwich Mean Time) and then adjusting that time for display based on the time zone you're in plus whatever DST adjustment is required, if any.
48.) Swamp Fox - 12/04/2013
[QUOTE=DParker;13161] But, if the timestamp was captured during DST then the software must adjust it by [I]adding[/I] 1 hour because, as you noted, DST means that you "spring forward" relative to ST, and the timestamp is always in ST form regardless of when it was captured.
[/QUOTE]
Are you telling me that if I match my camera to my watch during DST, the damn camera is going to time stamp any pics taken during DST an hour [COLOR="#FF0000"]LATER[/COLOR] than what the watch on my wrist says???
Bastards!!!
[/QUOTE]
Are you telling me that if I match my camera to my watch during DST, the damn camera is going to time stamp any pics taken during DST an hour [COLOR="#FF0000"]LATER[/COLOR] than what the watch on my wrist says???
Bastards!!!
49.) Swamp Fox - 12/04/2013
I'll check two out of three models today to see if you can adjust for time zone. I don't recall having to do that, though.
50.) DParker - 12/04/2013
[QUOTE=Swamp Fox;13164]Are you telling me that if I match my camera to my watch during DST, the damn camera is going to time stamp any pics taken during DST an hour EARLIER than what the watch on my wrist says???
Bastards!!![/QUOTE]
Hey...if you're going to lie to them it only seems fair that they get to play fast and loose with things too. :wink
But the actual "timestamp" stored is strictly an internal value. Anything that is displayed to you, the user, should be adjusted (if required) for DST so that what you see is what you expect. But if the software is forgetting to do that for some reason then you end up seeing the unadjusted value.
Bastards!!![/QUOTE]
Hey...if you're going to lie to them it only seems fair that they get to play fast and loose with things too. :wink
But the actual "timestamp" stored is strictly an internal value. Anything that is displayed to you, the user, should be adjusted (if required) for DST so that what you see is what you expect. But if the software is forgetting to do that for some reason then you end up seeing the unadjusted value.
51.) Swamp Fox - 12/04/2013
Right...I meant [COLOR="#FF0000"]earlier[/COLOR] but then got confused and edited it to Later...
So if my time stamp says the big buck was there at 3:07 during DST, he was actually there at 4:07...Right?
Again I say: Bastards!!
So if my time stamp says the big buck was there at 3:07 during DST, he was actually there at 4:07...Right?
Again I say: Bastards!!
52.) Swamp Fox - 12/04/2013
The next camera I set out, I won't do my DST consistency trick: I'll input Standard Time. Since my WG cameras synch exactly between time stamp and Details only during ST when I "falsely" input DST, I would expect to see discrepancies again. Who knows what will happen with the Bushnells.
This is why everyone hates computer programmers...
:wink
This is why everyone hates computer programmers...
:wink
53.) DParker - 12/04/2013
Think of an extremely over-simplified analogy involving international currency exchange. Say you have a bank in the U.S. that caters to customers all over the world, and your bank provides one service and one service only: Passbook savings accounts that pay no interest (hey, I told you it was extremely over-simplified). Now, being a U.S. business your bank stores and tracks all deposits and account funds in US$. In other words, the US$ is your internal standard. But your customers are all over the world, and many (perhaps most) are in countries that use currencies other than US$ When these customers make deposits and withdrawals they do so by specifying amounts their native currencies. So, in keeping with our simplification, let's assume that the exchange rates for all foreign (non-US) currencies relative to the US$ remain at constant values for the months of Jan - Jun, and then switch over to another set of constant values from Jul through Dec. For example, let's say that for the first half of each year the Euro is equivalent to exactly US$1.00, and this is considered the "standard". But during the 2nd half the Euro is worth US$1.20. So when your European customers make deposits and/or withdrawals, you have to convert the amounts of those transactions, which are specified in Euros, to/from your internal standard currency, which is US$.
So, let's say you have an Italian business customer, [I]I Burattini di Geppetto[/I] ([I]Geppetto's Puppets[/I]). Geppetto opens an account with your bank on July 15 and deposits €10,000 (note that I'm using commas and decimal points per U.S. custom, which is the opposite of their European use). Since this transaction is occurring during the 2nd half of the year your banking software converts this amount based on the US$1.20 exchange rate, so you credit Gepetto's new account with $12,000. Now let's say that no more deposits or withdrawals occur for the next 6 months, and that each time Gepetto inquires about his account balance he is told that he has €10,000, because your software converts the US$12,000 you have stored internally based on the current €1.20 exchange rate. But then, when he inquires about his balance again on the following Jan 1 the other exchange rate (€1.00 = US$1.00) is now in effect. Because of that you report his balance as €12,000. The actual US$ balance in his account has not changed at all, but because of the change in exchange rate it appears to your customer as though it has. Now, if he were to then immediately request a withdrawal of €100 you would send him that amount, and debit his account by US$100, because that's what €100 translates to at that time of year. So internally, his balance is now US$11,900. And the new balance displayed to Geppetto after his withdrawal is €11,900 (again, because of the exchange rate is exactly 1-for-1). Now let's say that the customer doesn't perform any more transactions until the following Aug, when the €1.00 -> US$1.20 rate is in effect again. This time he inquires about his balance and gets a result of €9,916.66 (ignoring the rounding error) because of exchange rate adjustment. He then asks to withdraw €250, which results in his account being debited by US$300, and the internal balance being US$11,660. But his withdrawal receipt show his balance as being €9,666.66 due to exchange rate adjustment.
Now...let's modify the withdrawal scenario slightly and assume that your banking software has a bug, such that when balances are displayed on withdrawal transaction records your software neglects to apply the current exchange rate conversion. In that case, after Geppetto withdraws his €250 (US$300) his withdrawal receipt shows that his new balance is €11,660. But his pre-withdrawal balance was displayed to him as €9,916.66! What the hell?! How did his balance increase as a result of a withdrawal?! Answer: It didn't. The software just goofed by not performing the proper adjustment on the amount in order to display it in terms that he wants to see it...its value in his native Euros.
Does that help at all?
So, let's say you have an Italian business customer, [I]I Burattini di Geppetto[/I] ([I]Geppetto's Puppets[/I]). Geppetto opens an account with your bank on July 15 and deposits €10,000 (note that I'm using commas and decimal points per U.S. custom, which is the opposite of their European use). Since this transaction is occurring during the 2nd half of the year your banking software converts this amount based on the US$1.20 exchange rate, so you credit Gepetto's new account with $12,000. Now let's say that no more deposits or withdrawals occur for the next 6 months, and that each time Gepetto inquires about his account balance he is told that he has €10,000, because your software converts the US$12,000 you have stored internally based on the current €1.20 exchange rate. But then, when he inquires about his balance again on the following Jan 1 the other exchange rate (€1.00 = US$1.00) is now in effect. Because of that you report his balance as €12,000. The actual US$ balance in his account has not changed at all, but because of the change in exchange rate it appears to your customer as though it has. Now, if he were to then immediately request a withdrawal of €100 you would send him that amount, and debit his account by US$100, because that's what €100 translates to at that time of year. So internally, his balance is now US$11,900. And the new balance displayed to Geppetto after his withdrawal is €11,900 (again, because of the exchange rate is exactly 1-for-1). Now let's say that the customer doesn't perform any more transactions until the following Aug, when the €1.00 -> US$1.20 rate is in effect again. This time he inquires about his balance and gets a result of €9,916.66 (ignoring the rounding error) because of exchange rate adjustment. He then asks to withdraw €250, which results in his account being debited by US$300, and the internal balance being US$11,660. But his withdrawal receipt show his balance as being €9,666.66 due to exchange rate adjustment.
Now...let's modify the withdrawal scenario slightly and assume that your banking software has a bug, such that when balances are displayed on withdrawal transaction records your software neglects to apply the current exchange rate conversion. In that case, after Geppetto withdraws his €250 (US$300) his withdrawal receipt shows that his new balance is €11,660. But his pre-withdrawal balance was displayed to him as €9,916.66! What the hell?! How did his balance increase as a result of a withdrawal?! Answer: It didn't. The software just goofed by not performing the proper adjustment on the amount in order to display it in terms that he wants to see it...its value in his native Euros.
Does that help at all?
54.) DParker - 12/04/2013
[QUOTE=Swamp Fox;13170]The next camera I set out, I won't do my DST consistency trick: I'll input Standard Time. Since my WG cameras synch exactly between time stamp and Details only during ST when I "falsely" input DST, I would expect to see discrepancies again. Who knows what will happen with the Bushnells.[/QUOTE]
The thing to do is to not worry about ST vs DST and just input the actual current time that your watch says it is (assuming your watch is properly in sync with whatever the current time standard is for your area). If the camera's software is operating properly it will take care of converting the input time if necessary. Don't try to anticipate, translate or otherwise "trick" the camera into doing something. Just tell it what time it currently is and let it do the rest.
[QUOTE=Swamp Fox;13170]This is why everyone hates computer programmers...
:wink[/QUOTE]
You don't know the half of it.
The thing to do is to not worry about ST vs DST and just input the actual current time that your watch says it is (assuming your watch is properly in sync with whatever the current time standard is for your area). If the camera's software is operating properly it will take care of converting the input time if necessary. Don't try to anticipate, translate or otherwise "trick" the camera into doing something. Just tell it what time it currently is and let it do the rest.
[QUOTE=Swamp Fox;13170]This is why everyone hates computer programmers...
:wink[/QUOTE]
You don't know the half of it.
55.) Swamp Fox - 12/04/2013
Yes, I meant the next camera to go out during ST, which should be shortly.
I think it's safe to say I have a bug in the WGs, though, and since the one Bushnell I've tried so far acts the same way as the WG (for DST at least) in Bushnell as well?
Where Details is important is only in locating, saving and delete pictures quickly. What's more important is to be able to trust the time stamp on each individual picture, synching it with my watch showing Local Time.
Given the info we have so far, then, have we established that the time stamp ON AN IMAGE is untrustworthy during both DST and ST periods? And that the time stamp on an image taken during DST seems to be one hour earlier than the Local Time the picture was actually taken? And that this may be true for both the Wildgame and the Bushnell cameras?
I mean, I assumed my time stamp corresponds to the time standard I input to the camera when I set it up, and that does not seem to be the case. If I set up a camera at 3:05 DST and the time stamp on the first picture is 3:07, I want to know that it was really 3:07 DST that the pic was taken...But it doesn't seem as if I can believe that.
I think it's safe to say I have a bug in the WGs, though, and since the one Bushnell I've tried so far acts the same way as the WG (for DST at least) in Bushnell as well?
Where Details is important is only in locating, saving and delete pictures quickly. What's more important is to be able to trust the time stamp on each individual picture, synching it with my watch showing Local Time.
Given the info we have so far, then, have we established that the time stamp ON AN IMAGE is untrustworthy during both DST and ST periods? And that the time stamp on an image taken during DST seems to be one hour earlier than the Local Time the picture was actually taken? And that this may be true for both the Wildgame and the Bushnell cameras?
I mean, I assumed my time stamp corresponds to the time standard I input to the camera when I set it up, and that does not seem to be the case. If I set up a camera at 3:05 DST and the time stamp on the first picture is 3:07, I want to know that it was really 3:07 DST that the pic was taken...But it doesn't seem as if I can believe that.
56.) bluecat - 12/04/2013
If Ron Popeil designed a trail cam you would "set it and forget it".
And it would only cost three [B]easy[/B] payments of 39.99.
And if you act now you would get the Drury Bros Dream Season.
And it would only cost three [B]easy[/B] payments of 39.99.
And if you act now you would get the Drury Bros Dream Season.
57.) DParker - 12/04/2013
[QUOTE=Swamp Fox;13173]Yes, I meant the next camera to go out during ST, which should be shortly.
I think it's safe to say I have a bug in the WGs, though, and since the one Bushnell I've tried so far acts the same way as the WG (for DST at least) in Bushnell as well?[/quote]
We don't know that (or at least [I]I[/I] don't know that) yet, since I haven't seen examples of the time displays for photos and "Detail lists" from both cameras that include photos taken during DST *AND* during LST so that we can compare them see whether or not their behaviors are at least internally consistent.
[QUOTE=Swamp Fox;13173]Where Details is important is only in locating, saving and delete pictures quickly. What's more important is to be able to trust the time stamp on each individual picture, synching it with my watch showing Local Time.[/quote]
Here we have a problem of managing expectations. If the camera software is smart enough to be cognizant of, and properly adjust for DST - in all cases (with no bugs) - then the time displayed by your watch when you're viewing photos is irrelevant, and you cannot expect it to always be synchronized with times that have occurred in the past when different time standards may have been in effect. What is relevant is what your watch [I]would have[/I] displayed at the time that the photo was taken. For instance, if the photo was taken at 2:00pm while DST was in effect, your watch would have also said it was 2:00pm [I]at that same time[/I]. But if you wait and view the photo some time later when Standard Time is in effect, the photo time of 2:00pm (which was the time when it was taken) refers to a time of day that your watch would now (at the time that you're viewing the photo) represent as 1:00pm, because the time standard in effect at picture-taking time is different from the standard in effect at picture-viewing time.
[QUOTE=Swamp Fox;13173]Given the info we have so far, then, have we established that the time stamp ON AN IMAGE is untrustworthy during both DST and ST periods? And that the time stamp on an image taken during DST seems to be one hour earlier than the Local Time the picture was actually taken? And that this may be true for both the Wildgame and the Bushnell cameras?
I mean, I assumed my time stamp corresponds to the time standard I input to the camera when I set it up, and that does not seem to be the case.[/quote]
Well, that's the thing. You didn't input a time standard. You input a time [I]value[/I] that the camera interpreted based on the time standard currently in effect per the rules for the day you set the clock. If you set the clock when Standard Time was in effect and your watch said 2:00pm, but entered it as 3:00pm because you were trying to trick the camera into using the DST standard you wanted, the camera is going to treat that as 3:00pm Standard Time (how would it know that you're entering time according to some standard that isn't in effect at the moment?) and set the internal clock accordingly. Later, when photos are taken during the time when DST is in effect, and you attempt to view those photos, it's going to compute the display time based on the assumption that it's internal clock was tracking ST, and adjust the displayed times for DST accordingly.
[QUOTE=Swamp Fox;13173]If I set up a camera at 3:05 DST and the time stamp on the first picture is 3:07, I want to know that it was really 3:07 DST that the pic was taken...But it doesn't seem as if I can believe that.[/QUOTE]
If there is in fact a bug, that's correct. But the good news is that, if that bug is consistent, and you know on what dates DST goes into/out of effect in your area, you can at least reliably adjust your interpretation of the times displayed with the photos.
All of this boils down to confusion that results from the fact that the answer to the simple question, "What time is it?" is a potentially complicated one, and is heavily dependent on context.
I think it's safe to say I have a bug in the WGs, though, and since the one Bushnell I've tried so far acts the same way as the WG (for DST at least) in Bushnell as well?[/quote]
We don't know that (or at least [I]I[/I] don't know that) yet, since I haven't seen examples of the time displays for photos and "Detail lists" from both cameras that include photos taken during DST *AND* during LST so that we can compare them see whether or not their behaviors are at least internally consistent.
[QUOTE=Swamp Fox;13173]Where Details is important is only in locating, saving and delete pictures quickly. What's more important is to be able to trust the time stamp on each individual picture, synching it with my watch showing Local Time.[/quote]
Here we have a problem of managing expectations. If the camera software is smart enough to be cognizant of, and properly adjust for DST - in all cases (with no bugs) - then the time displayed by your watch when you're viewing photos is irrelevant, and you cannot expect it to always be synchronized with times that have occurred in the past when different time standards may have been in effect. What is relevant is what your watch [I]would have[/I] displayed at the time that the photo was taken. For instance, if the photo was taken at 2:00pm while DST was in effect, your watch would have also said it was 2:00pm [I]at that same time[/I]. But if you wait and view the photo some time later when Standard Time is in effect, the photo time of 2:00pm (which was the time when it was taken) refers to a time of day that your watch would now (at the time that you're viewing the photo) represent as 1:00pm, because the time standard in effect at picture-taking time is different from the standard in effect at picture-viewing time.
[QUOTE=Swamp Fox;13173]Given the info we have so far, then, have we established that the time stamp ON AN IMAGE is untrustworthy during both DST and ST periods? And that the time stamp on an image taken during DST seems to be one hour earlier than the Local Time the picture was actually taken? And that this may be true for both the Wildgame and the Bushnell cameras?
I mean, I assumed my time stamp corresponds to the time standard I input to the camera when I set it up, and that does not seem to be the case.[/quote]
Well, that's the thing. You didn't input a time standard. You input a time [I]value[/I] that the camera interpreted based on the time standard currently in effect per the rules for the day you set the clock. If you set the clock when Standard Time was in effect and your watch said 2:00pm, but entered it as 3:00pm because you were trying to trick the camera into using the DST standard you wanted, the camera is going to treat that as 3:00pm Standard Time (how would it know that you're entering time according to some standard that isn't in effect at the moment?) and set the internal clock accordingly. Later, when photos are taken during the time when DST is in effect, and you attempt to view those photos, it's going to compute the display time based on the assumption that it's internal clock was tracking ST, and adjust the displayed times for DST accordingly.
[QUOTE=Swamp Fox;13173]If I set up a camera at 3:05 DST and the time stamp on the first picture is 3:07, I want to know that it was really 3:07 DST that the pic was taken...But it doesn't seem as if I can believe that.[/QUOTE]
If there is in fact a bug, that's correct. But the good news is that, if that bug is consistent, and you know on what dates DST goes into/out of effect in your area, you can at least reliably adjust your interpretation of the times displayed with the photos.
All of this boils down to confusion that results from the fact that the answer to the simple question, "What time is it?" is a potentially complicated one, and is heavily dependent on context.
58.) bluecat - 12/04/2013
[QUOTE=Swamp Fox;13173]Yes, I meant the next camera to go out during ST, which should be shortly.
I think it's safe to say I have a bug in the WGs, though, and since the one Bushnell I've tried so far acts the same way as the WG (for DST at least) in Bushnell as well?
Where Details is important is only in locating, saving and delete pictures quickly. What's more important is to be able to trust the time stamp on each individual picture, synching it with my watch showing Local Time.
Given the info we have so far, then, have we established that the time stamp ON AN IMAGE is untrustworthy during both DST and ST periods? And that the time stamp on an image taken during DST seems to be one hour earlier than the Local Time the picture was actually taken? And that this may be true for both the Wildgame and the Bushnell cameras?
I mean, I assumed my time stamp corresponds to the time standard I input to the camera when I set it up, and that does not seem to be the case. If I set up a camera at 3:05 DST and the time stamp on the first picture is 3:07, I want to know that it was really 3:07 DST that the pic was taken...But it doesn't seem as if I can believe that.[/QUOTE]
Get a clock and a thermometer and set them up so they are included in the picture. Low tech but you would know exact time and temperature.
I think it's safe to say I have a bug in the WGs, though, and since the one Bushnell I've tried so far acts the same way as the WG (for DST at least) in Bushnell as well?
Where Details is important is only in locating, saving and delete pictures quickly. What's more important is to be able to trust the time stamp on each individual picture, synching it with my watch showing Local Time.
Given the info we have so far, then, have we established that the time stamp ON AN IMAGE is untrustworthy during both DST and ST periods? And that the time stamp on an image taken during DST seems to be one hour earlier than the Local Time the picture was actually taken? And that this may be true for both the Wildgame and the Bushnell cameras?
I mean, I assumed my time stamp corresponds to the time standard I input to the camera when I set it up, and that does not seem to be the case. If I set up a camera at 3:05 DST and the time stamp on the first picture is 3:07, I want to know that it was really 3:07 DST that the pic was taken...But it doesn't seem as if I can believe that.[/QUOTE]
Get a clock and a thermometer and set them up so they are included in the picture. Low tech but you would know exact time and temperature.
59.) Swamp Fox - 12/04/2013
[ATTACH=CONFIG]308[/ATTACH]
Okay, to contradict my last post, everything matches up properly here....during ST. Time input is correct, image time stamp is correct, and Details time info is correct. Which may mean what I said above about fooling the camera during ST didn't actually happen in my example above if the image and Details times synched up. Maybe I input ST when I meant to input DST.Back to the lab on that one.
But the DST problem probably continues...
Okay, to contradict my last post, everything matches up properly here....during ST. Time input is correct, image time stamp is correct, and Details time info is correct. Which may mean what I said above about fooling the camera during ST didn't actually happen in my example above if the image and Details times synched up. Maybe I input ST when I meant to input DST.Back to the lab on that one.
But the DST problem probably continues...
60.) bluecat - 12/04/2013
I wouldn't mess with that buck. Even though it has plenty of girth, the antler configuration is all wrong. Pass.
61.) bluecat - 12/04/2013
Question, do you have any tires with air in them? Just curious.
62.) Swamp Fox - 12/04/2013
[QUOTE=DParker;13175]
All of this boils down to confusion that results from the fact that the answer to the simple question, "What time is it?" is a potentially complicated one, and is heavily dependent on context.[/QUOTE]
Okay, now you're screwing with me. :p
In case it needs to be clarified, if my watch is on DST and I input my camera time to DST, I want my image time stamp to show DST.
If my watch is on ST because it IS ST, and I am viewing a picture that was taken during DST, I want the time stamp to be a DST stamp, because I can do the math as long as I know what day and month it is...LOL.
All of this boils down to confusion that results from the fact that the answer to the simple question, "What time is it?" is a potentially complicated one, and is heavily dependent on context.[/QUOTE]
Okay, now you're screwing with me. :p
In case it needs to be clarified, if my watch is on DST and I input my camera time to DST, I want my image time stamp to show DST.
If my watch is on ST because it IS ST, and I am viewing a picture that was taken during DST, I want the time stamp to be a DST stamp, because I can do the math as long as I know what day and month it is...LOL.
63.) Swamp Fox - 12/04/2013
[QUOTE=bluecat;13179]Question, do you have any tires with air in them? Just curious.[/QUOTE]
Somebody spiked them last week...All 12. And broke the keys off/stole them.
Somebody spiked them last week...All 12. And broke the keys off/stole them.
64.) DParker - 12/04/2013
[QUOTE=Swamp Fox;13177][ATTACH=CONFIG]308[/ATTACH]
Okay, to contradict my last post, everything matches up properly here....during ST. Time input is correct, image time stamp is correct, and Details time info is correct. Which may mean what I said above about fooling the camera during ST didn't actually happen in my example above if the image and Details times synched up. Maybe I input ST when I meant to input DST.Back to the lab on that one.[/QUOTE]
Damned programmers! :wink
[QUOTE=bluecat;13178]I wouldn't mess with that buck. Even though it has plenty of girth, the antler configuration is all wrong. Pass.[/QUOTE]
It looks like it has a case of the mad cow, too.
Okay, to contradict my last post, everything matches up properly here....during ST. Time input is correct, image time stamp is correct, and Details time info is correct. Which may mean what I said above about fooling the camera during ST didn't actually happen in my example above if the image and Details times synched up. Maybe I input ST when I meant to input DST.Back to the lab on that one.[/QUOTE]
Damned programmers! :wink
[QUOTE=bluecat;13178]I wouldn't mess with that buck. Even though it has plenty of girth, the antler configuration is all wrong. Pass.[/QUOTE]
It looks like it has a case of the mad cow, too.
65.) Swamp Fox - 12/04/2013
[QUOTE=bluecat;13178]I wouldn't mess with that buck. Even though it has plenty of girth, the antler configuration is all wrong. Pass.[/QUOTE]
That would be a good one in Pennsylvania...
:-)
That would be a good one in Pennsylvania...
:-)
66.) DParker - 12/04/2013
[QUOTE=Swamp Fox;13180]Okay, now you're screwing with me. :p[/QUOTE]
Nah. If I wanted to screw with you I'd go back and drag out that UTC issue, and then toss in some of the weird local exceptions to time zone standards that exist in some political areas. For instance: [URL="http://ontimezone.com/exceptions.php"]http://ontimezone.com/exceptions.php[/URL]
[QUOTE=Swamp Fox;13180]In case it needs to be clarified, if my watch is on DST and I input my camera time to DST, I want my image time stamp to show DST.[/QUOTE]
No clarification needed, and your expectation is a reasonable one...provided the image was also taken when DST was in effect. If it was taken when Standard Time was in effect then that's what the time displayed with the image will (or at least, should) show...because that was the time when the photo was taken. The camera neither knows nor cares what your watch says. It only knows what time it is (and was) based on standard time expression rules. In other words, the time displayed on the image means, "This is what time it was - according to local time rules in effect at that time - when this photo was taken"...not, "This is what time your watch would say this photo was taken if you never, ever changed the time on your watch to adjust for local time standard changes".
[QUOTE=Swamp Fox;13180]If my watch is on ST because it IS ST, and I am viewing a picture that was taken during DST, I want the time stamp to be a DST stamp, because I can do the math as long as I know what day and month it is...LOL.[/QUOTE]
Nah. If I wanted to screw with you I'd go back and drag out that UTC issue, and then toss in some of the weird local exceptions to time zone standards that exist in some political areas. For instance: [URL="http://ontimezone.com/exceptions.php"]http://ontimezone.com/exceptions.php[/URL]
[QUOTE=Swamp Fox;13180]In case it needs to be clarified, if my watch is on DST and I input my camera time to DST, I want my image time stamp to show DST.[/QUOTE]
No clarification needed, and your expectation is a reasonable one...provided the image was also taken when DST was in effect. If it was taken when Standard Time was in effect then that's what the time displayed with the image will (or at least, should) show...because that was the time when the photo was taken. The camera neither knows nor cares what your watch says. It only knows what time it is (and was) based on standard time expression rules. In other words, the time displayed on the image means, "This is what time it was - according to local time rules in effect at that time - when this photo was taken"...not, "This is what time your watch would say this photo was taken if you never, ever changed the time on your watch to adjust for local time standard changes".
[QUOTE=Swamp Fox;13180]If my watch is on ST because it IS ST, and I am viewing a picture that was taken during DST, I want the time stamp to be a DST stamp, because I can do the math as long as I know what day and month it is...LOL.[/QUOTE]
67.) Swamp Fox - 12/04/2013
I'll never forget driving from Utah through Arizona and into Nevada a few years ago. I think the time changed about 5 times on us that day. I was so confused, LOL. We might not have even made it into Nevada. I remember Arizona as being the big mess.
68.) bluecat - 12/04/2013
Think about how confusing it was for this guy.
[url]http://www.labyrinthina.com/electronicfog.htm[/url]
I had never made it from Andros to Palm Beach in less than 75 minutes, even on a direct route. Our course on this flight was quite indirect and probably covered close to 250 miles. How could the airplane travel 250 miles in 47 minutes? We taxied to customs, ending the fortuitous flight. We didn't talk about it for a long time.
[url]http://www.labyrinthina.com/electronicfog.htm[/url]
I had never made it from Andros to Palm Beach in less than 75 minutes, even on a direct route. Our course on this flight was quite indirect and probably covered close to 250 miles. How could the airplane travel 250 miles in 47 minutes? We taxied to customs, ending the fortuitous flight. We didn't talk about it for a long time.
69.) luv2bowhunt - 12/04/2013
Wait, do you expect us to believe you actually KNOW how to set a watch???????
Come on Chris, at least keep the storyline believable.
Come on Chris, at least keep the storyline believable.
70.) Swamp Fox - 12/04/2013
If the watch has two or fewer knobs or buttons on it, I can manage, but you should see me with a Casio....
LOL
LOL
71.) Ventilator - 12/04/2013
I just think the damn Busbice`s are out to get you! :grin:
72.) Swamp Fox - 12/04/2013
LOL...
Now I can't wait til Daylight Savings Tme again, to see if I can experiment more carefully and confuse myself even further!
I doubt I still have any SD cards with both DST and LST pictures on them at this point, but if I come across any I'll be sure to let everyone know...:wink
So, we wait for Spring...:dig:
Now I can't wait til Daylight Savings Tme again, to see if I can experiment more carefully and confuse myself even further!
I doubt I still have any SD cards with both DST and LST pictures on them at this point, but if I come across any I'll be sure to let everyone know...:wink
So, we wait for Spring...:dig:
73.) DParker - 12/04/2013
[QUOTE=Swamp Fox;13200]So, we wait for Spring...:dig:[/QUOTE]
I'm still waiting for it to be over (it's 80°F here right now). Though my wait will be over tomorrow morning....big time.
I'm still waiting for it to be over (it's 80°F here right now). Though my wait will be over tomorrow morning....big time.
74.) Swamp Fox - 12/04/2013
It's 80ish here, too. And we got soaked last night when the forecast was light rain [B]Tomorrow. [/B]
Timed my trip to Camp Swampy wrong AGAIN.
I think my next thread will be about how I'm cornfused about internet weather forecast services...:bang::rage:
Timed my trip to Camp Swampy wrong AGAIN.
I think my next thread will be about how I'm cornfused about internet weather forecast services...:bang::rage:
75.) DParker - 12/04/2013
Probably the best local TV meteorologist has a blog on which he posted just a couple of hours ago regarding his forecast for tomorrow and the next 6 days in general....
[quote]The Metroplex is going to be entombed in ice.[/quote]
"entombed".
[quote]The Metroplex is going to be entombed in ice.[/quote]
"entombed".
76.) Swamp Fox - 12/04/2013
This is appropriate:
[url]http://www.wildgameinnovations.com/cornfused.html[/url]
[url]http://www.wildgameinnovations.com/cornfused.html[/url]
77.) Swamp Fox - 12/04/2013
You should plan something dramatic for next week when you rise from the grave...
78.) DParker - 12/04/2013
Going zombie isn't dramatic enough already?
79.) Swamp Fox - 12/04/2013
It's been done to death...
[Insert Smilie filing nails with jaded look...]
Show me something new.
:pop:
[Insert Smilie filing nails with jaded look...]
Show me something new.
:pop:
80.) billy b - 12/04/2013
[QUOTE=DParker;13204]Probably the best local TV meteorologist has a blog on which he posted just a couple of hours ago regarding his forecast for tomorrow and the next 6 days in general....
"entombed".[/QUOTE]
Who is it since Steve Mccalley left?:cf:
"entombed".[/QUOTE]
Who is it since Steve Mccalley left?:cf:
81.) DParker - 12/04/2013
[QUOTE=billy b;13212]Who is it since Steve Mccalley left?:cf:[/QUOTE]
Actually, it was a post by McCauley that I was quoting (though I think Pete Delkus took over for him at WFAA - Channel 8).
Actually, it was a post by McCauley that I was quoting (though I think Pete Delkus took over for him at WFAA - Channel 8).
82.) billy b - 12/05/2013
Mccalley was the weekend man on 8 for a good many years although he was relatively young, he was the best since Harold Taft in the 50's & 60's. That being said, I do like Delkus.
83.) Swamp Fox - 12/05/2013
What makes these guys so good? Do they make balloon animals or juggle chainsaws while they do the weather?
I wish Scoutlookweather.com had someone like that...Because the forecasts on their own suck like a Hoover...:rage:
I wish Scoutlookweather.com had someone like that...Because the forecasts on their own suck like a Hoover...:rage:
84.) DParker - 12/05/2013
McCauley was quite accurate and very good at explaining weather phenomenon in layman's terms that informed and didn't bore you to tears. Delkus is good because...
A) He's an avid hunter and isn't afraid to talk about it on the air, and...
B) He gives Dale Hansen (the best sports news guy ever) no end of good natured grief. Their back-and-forth can be really entertaining.
Oh, and he's a decent meteorologist too.
A) He's an avid hunter and isn't afraid to talk about it on the air, and...
B) He gives Dale Hansen (the best sports news guy ever) no end of good natured grief. Their back-and-forth can be really entertaining.
Oh, and he's a decent meteorologist too.
85.) billy b - 12/05/2013
A+, I completely agree, thats why Texans are better that fereners from N.C. or pensilsnania, they have sucky weathermen.:poke:
86.) luv2bowhunt - 12/05/2013
Our weatherman went deer hunting on opening day on Monday...........saw nothing.
No surprise there. From all the reports I'm getting, and I talk to a ton of hunters, this is the slowest rifle season in a long, long, time.
..........OK, now back to the electronically inept Tarheel............wait 'till after Christmas, there'll be a GPS, a clock radio, or an Android device he'll have no idea how to use.
This is the stuff that keeps me coming back to this lame site.
No surprise there. From all the reports I'm getting, and I talk to a ton of hunters, this is the slowest rifle season in a long, long, time.
..........OK, now back to the electronically inept Tarheel............wait 'till after Christmas, there'll be a GPS, a clock radio, or an Android device he'll have no idea how to use.
This is the stuff that keeps me coming back to this lame site.
87.) billy b - 12/05/2013
There will be no Android devices for Swampy, he will not under any circumstances give up hie NCIS flip phone:bang:
88.) luv2bowhunt - 12/05/2013
Hard to butt dial someone with a flip phone, so he's got that going at least.:tu:
89.) Swamp Fox - 12/05/2013
LOL...
I considered a smart phone for about two minutes and decided they seem too delicate for me, and I don't want the damn internet in my pocket anyway.
My little texting phone is fine, but still too delicate for me. Plus, not that I text a lot, but if were to get a new phone for all-around it would have to have a good qwerty keyboard with actual keys, and those seem rare as hens' teeth anymore.
I also have an older Casio GzOne flip phone that 's weatherproof, waterproof etc. and that's what I carry in the woods or on the water on the rare occasions that I carry a phone out there at all. Texting is by the old mash-the-numbers-til-you-get-the-right-letter method, so I don't bother. Life's too short to send stupid texts that way, and 99% of texts are avoidable and/or a waste of valuable ozone . You kids keep jabbering away and running all over my lawn, but leave me out of it. LOL Casio makes a very rugged smartphone but, as I say, I don't have any great need for it.
Some day I'll tell y'all about my candybar phone that's still in use. :wink
And believe it or not, I'm pretty good with a GPS---the actual woods and water kind, anyway. I'm not all that impressed with the in-your-car-because-you-can't-read-a-map kind. :p
I considered a smart phone for about two minutes and decided they seem too delicate for me, and I don't want the damn internet in my pocket anyway.
My little texting phone is fine, but still too delicate for me. Plus, not that I text a lot, but if were to get a new phone for all-around it would have to have a good qwerty keyboard with actual keys, and those seem rare as hens' teeth anymore.
I also have an older Casio GzOne flip phone that 's weatherproof, waterproof etc. and that's what I carry in the woods or on the water on the rare occasions that I carry a phone out there at all. Texting is by the old mash-the-numbers-til-you-get-the-right-letter method, so I don't bother. Life's too short to send stupid texts that way, and 99% of texts are avoidable and/or a waste of valuable ozone . You kids keep jabbering away and running all over my lawn, but leave me out of it. LOL Casio makes a very rugged smartphone but, as I say, I don't have any great need for it.
Some day I'll tell y'all about my candybar phone that's still in use. :wink
And believe it or not, I'm pretty good with a GPS---the actual woods and water kind, anyway. I'm not all that impressed with the in-your-car-because-you-can't-read-a-map kind. :p
90.) DParker - 12/05/2013
[QUOTE=Swamp Fox;13242]LOL...
I considered a smart phone for about two minutes and decided they seem too delicate for me[/quote]
Lying to your web cams, physically abusing your phones. Why do you hate technology? As for the "too delicate" thing...
[URL="http://www.otterbox.com/Galaxy-S4-Defender-Series-Build-Your-Own-Case/sam2-galaxy-s4-set,default,pd.html"]Otter Box "Defender" Series[/URL]
I have my Samsung Galaxy S4 safely nestled in one of these. It's tough as nails and water resistant as well (no, you can't take it scuba diving...but if you can't keep from submerging your cell phone in standing water you have bigger problems.) Shop around and you can find them for somewhere in the neighborhood of $35, like I did.
[QUOTE=Swamp Fox;13242], and I don't want the damn internet in my pocket anyway.[/QUOTE]
Is that a web site in your pants, or are you just glad to see me?
I used to not be a fan of cell phones in general (even though I carried one for emergencies and so my family could reach me if need be), but since I got my Galaxy (running Android) I'm a convert. The trick is to come to the realization that they're no longer phones that can do other stuff as well. They're pocket computers and GPS units with numerous connectivity mechanisms that just happen to also let you text and make phone calls, both of which constitute a very small minority of the uses I put mine to.
I considered a smart phone for about two minutes and decided they seem too delicate for me[/quote]
Lying to your web cams, physically abusing your phones. Why do you hate technology? As for the "too delicate" thing...
[URL="http://www.otterbox.com/Galaxy-S4-Defender-Series-Build-Your-Own-Case/sam2-galaxy-s4-set,default,pd.html"]Otter Box "Defender" Series[/URL]
I have my Samsung Galaxy S4 safely nestled in one of these. It's tough as nails and water resistant as well (no, you can't take it scuba diving...but if you can't keep from submerging your cell phone in standing water you have bigger problems.) Shop around and you can find them for somewhere in the neighborhood of $35, like I did.
[QUOTE=Swamp Fox;13242], and I don't want the damn internet in my pocket anyway.[/QUOTE]
Is that a web site in your pants, or are you just glad to see me?
I used to not be a fan of cell phones in general (even though I carried one for emergencies and so my family could reach me if need be), but since I got my Galaxy (running Android) I'm a convert. The trick is to come to the realization that they're no longer phones that can do other stuff as well. They're pocket computers and GPS units with numerous connectivity mechanisms that just happen to also let you text and make phone calls, both of which constitute a very small minority of the uses I put mine to.
91.) luv2bowhunt - 12/05/2013
Don't listen to him, they're junk, and part of a conspiracy by the man, to track our every movement, and send us subliminal messages to buy cars, savings bonds, and gov't employee insurance.
Stay in the 19th century with me. My Motorola walkie talkie still works fine, along with the compass and dowsing rods.
Stay in the 19th century with me. My Motorola walkie talkie still works fine, along with the compass and dowsing rods.
92.) Swamp Fox - 12/05/2013
If I carried a cell phone with me everywhere I go, it'd be submerged in no time and the screen would be opaque from scratches. It has to do with my shoe selection: if I am wearing dress shoes, the phone is pretty safe, but if I put boots on, watch out. It's an unusual correlation, but highly reliable. :wink
[QUOTE=DParker;13261]... The trick is to come to the realization that they're no longer phones that can do other stuff as well. They're pocket computers and GPS units with numerous connectivity mechanisms that just happen to also let you text and make phone calls...[/QUOTE]
Oh, don't stop! You're making me hot...
:fire:
[QUOTE=DParker;13261]... The trick is to come to the realization that they're no longer phones that can do other stuff as well. They're pocket computers and GPS units with numerous connectivity mechanisms that just happen to also let you text and make phone calls...[/QUOTE]
Oh, don't stop! You're making me hot...
:fire:
93.) DParker - 12/05/2013
[QUOTE=Swamp Fox;13269]Oh, don't stop! You're making me hot...[/QUOTE]
So, then.....that's [I]NOT[/I] a website in your pants?
So, then.....that's [I]NOT[/I] a website in your pants?
94.) Swamp Fox - 12/05/2013
No, just an 8-inch floppy.
95.) DParker - 12/05/2013
[QUOTE=Swamp Fox;13278]No, just an 8-inch floppy.[/QUOTE]
[video=youtube_share;oShTJ90fC34]http://youtu.be/oShTJ90fC34[/video]
[video=youtube_share;oShTJ90fC34]http://youtu.be/oShTJ90fC34[/video]