-
Anything ‘published’ on the web is viewed as intellectual property and, regardless of whether it displays a copyright symbol or not, is therefore copyrighted by the originator. The only exception to this is if there is a “free and unrestricted reuse” statement associated with the work.
In order to protect our members and TFL from possible litigation, all members must abide by the following new rules:
1. Copying and pasting entire articles from another site to TFL is strictly prohibited. The same applies to articles from print or other media, and to posting photographs taken of copyrighted pages or other media.
2. Copyright law provides for “fair use” of portions of a copyrighted work. You can copy no more than a SINGLE paragraph from the article to your post (3 or 4 sentences at most).
3. You must provide a link to the article along with the name of website. For example: ww.xxx.yyy/zzz (The Lower Thumbsuck Daily News).
4. You must provide, in your own words, a brief summary of the article AND your reasons for believing it will be of interest to TFL members. Failure to do so may result in the thread being closed or your post being deleted as a “cut and paste drive by.”
5. Photographs and other images are also copyrighted. "Hotlinking" of images (so that it appears in your message) from other sites is also prohibited unless you own rights to the image. If you wish to share an image, provide a clickable link to it.
Posts that do not follow these new guidelines will be altered or deleted by staff. Members who continue to violate this policy may lose their posting privileges at TFL.
Thank you for your cooperation and your participation in TFL, the leading online forum for firearms enthusiasts.
What time zone is TFL running in?
- Thread starter Gewehr98
- Start date
Gave up the clock lady on the phone a while ago...
For setting the time around the Gewehr98 household, it's either tuning to WWV on my Hammarlund SP-600 receiver, or I cheat and use AtomTime:
http://www.atomtime.com/
Anyway, the computer is pretty much dead nuts on with regards to the clock.
For setting the time around the Gewehr98 household, it's either tuning to WWV on my Hammarlund SP-600 receiver, or I cheat and use AtomTime:
http://www.atomtime.com/
Anyway, the computer is pretty much dead nuts on with regards to the clock.
Sounds like a cookie problem Gewehr98. The best clue is the blue bar at the bottom of your screen shot. You'll see that it says "All times are GMT". If your cookie lets TFL know that you are in the Eastern time zone, it should say "All times are GMT -5 hours".
Did you have to login at any time while the time warp was in effect?
[Edit]
Looks like you figured it out while I was looking and posting.
Did you have to login at any time while the time warp was in effect?
[Edit]
Looks like you figured it out while I was looking and posting.
It was kinda trippy, that's for sure.
I'd tweaked the computer for more speed earlier, but there's no way one can overclock a dual cpu PII-300 to wrinkle time via near-speed-of-light velocities. If I could, goodbye Intel and AMD!
Sam, I do use Kingston memory, suppose there's a connection?
I'd tweaked the computer for more speed earlier, but there's no way one can overclock a dual cpu PII-300 to wrinkle time via near-speed-of-light velocities. If I could, goodbye Intel and AMD!
Sam, I do use Kingston memory, suppose there's a connection?
Rich Lucibella
Staff
Fly-
Unknown. The important thing is that it shows the correct time for your zone, yes?
Rich
Unknown. The important thing is that it shows the correct time for your zone, yes?
Rich
Here's the deal with timezones.
vBulletin doesn't correct for timezone changes. This means there are two ways to work around it, and both are incorrect.
1) Set system time to local (EST/PST, whatever) and tell vbulletin that system time is always -5, -8, or whatever. This fixes U.S. DST-abiding locations, as system time is automatically corrected for local DST effects, but when DST (daylight savings time) goes away soon, but has serious drawbacks. Anyone with a user timezone set to GMT will have timestamps off by an hour during the summer and fall. Anyone in the few U.S. locations that don't use DST will have similar problems, and anyone outside the U.S. in a location that doesn't abide by North American DST changes will have similar problems.
2) Set system time to GMT. Since vbulletin only handles static offsets (-5, -8, etc.), when DST changes, times for people in DST zones will be off by an hour.
I consider 2 to be better than 1, but if there's a concensus that nobody cares about correctness and the only thing that's important is unobtrusive correct time for most Americans, I can change it back.
Here's my problem. TFL used to use choice 1). I'm a bit psychotic with timezones and wanted my offset to be 0. Unfortunately, that means during the summer TFL time for me was off by an hour. I realize it's a royal pain in the butt to change timezone offsets twice a year, but consider that not everyone, even inside the U.S., uses daylight savings time. Also, DST doesn't apply the same all throughout the continents - think about the effect of imposing North American DST changes on someone in Brazil
"Spring Ahead" doesn't work too well when you're approaching the winter months in South America. If you want to see what a disaster DST is just for Australia and Tasmania, check out http://www.dstc.qut.edu.au/DST/marg/daylight.html
The only way to fix this disaster is to hack up vbulletin, changing a database field in the process, and creating a zone for each potential combination of timezone and DST observance. And if you don't believe me, go to bladeforums right now and set your timezone offset to GMT. You'll notice it's an hour off.
Right now, for people in Eastern, Central, Mountain, or Pacific timezones, even though the displayed GMT offset is wrong, the time is correct. This was done (after a bit of confusion) to avoid having everyone's time become incorrect during the summer when nobody was likely to connect date changes with the disabling of DST correction. This "feature" will be going away in a week, and the offsets displayed by vbulletin will be universally correct. Until and unless a new vbulletin version has complete timezone functionality or I or someone else gets inspired to fix it, choices 1 and 2 are the only options.
vBulletin doesn't correct for timezone changes. This means there are two ways to work around it, and both are incorrect.
1) Set system time to local (EST/PST, whatever) and tell vbulletin that system time is always -5, -8, or whatever. This fixes U.S. DST-abiding locations, as system time is automatically corrected for local DST effects, but when DST (daylight savings time) goes away soon, but has serious drawbacks. Anyone with a user timezone set to GMT will have timestamps off by an hour during the summer and fall. Anyone in the few U.S. locations that don't use DST will have similar problems, and anyone outside the U.S. in a location that doesn't abide by North American DST changes will have similar problems.
2) Set system time to GMT. Since vbulletin only handles static offsets (-5, -8, etc.), when DST changes, times for people in DST zones will be off by an hour.
I consider 2 to be better than 1, but if there's a concensus that nobody cares about correctness and the only thing that's important is unobtrusive correct time for most Americans, I can change it back.
Here's my problem. TFL used to use choice 1). I'm a bit psychotic with timezones and wanted my offset to be 0. Unfortunately, that means during the summer TFL time for me was off by an hour. I realize it's a royal pain in the butt to change timezone offsets twice a year, but consider that not everyone, even inside the U.S., uses daylight savings time. Also, DST doesn't apply the same all throughout the continents - think about the effect of imposing North American DST changes on someone in Brazil
"Spring Ahead" doesn't work too well when you're approaching the winter months in South America. If you want to see what a disaster DST is just for Australia and Tasmania, check out http://www.dstc.qut.edu.au/DST/marg/daylight.htmlThe only way to fix this disaster is to hack up vbulletin, changing a database field in the process, and creating a zone for each potential combination of timezone and DST observance. And if you don't believe me, go to bladeforums right now and set your timezone offset to GMT. You'll notice it's an hour off.
Right now, for people in Eastern, Central, Mountain, or Pacific timezones, even though the displayed GMT offset is wrong, the time is correct. This was done (after a bit of confusion) to avoid having everyone's time become incorrect during the summer when nobody was likely to connect date changes with the disabling of DST correction. This "feature" will be going away in a week, and the offsets displayed by vbulletin will be universally correct. Until and unless a new vbulletin version has complete timezone functionality or I or someone else gets inspired to fix it, choices 1 and 2 are the only options.