Armed Polite Society
Main Forums => The Roundtable => Topic started by: RoadKingLarry on March 10, 2012, 10:30:44 PM
-
OK, who likes DST? Being that I work nights it isn't much of an issue with me but when I was on day shift I liked having the extra daylight at the end of the day
And, just in case you missed it we (most of us anyway) change to DST tonight.
-
Voted 3 times. =D
I both like and dislike it. I like the extra daylight at the end of the day, but I also like it being light out when I head to school early in the morning, and hate having to wait another two weeks for early morning daylight to reappear.
-
I'm just ticked off that nobody's seriously studying the the impact of an extra hour of sunlight on the climate, and instead get all wrapped up in CO2 and fossil fuels etc. :mad:
-
I do. Nice to have daylight to do stuff outside after work. Hell, it's nice to be able to go grocery shopping after work in the daylight.
I just wish we didn't change between DST and standard...
-
I hate it. As a programmer it plays merry hob with every date/time storage system you use as soon as you try and go time-zone neutral.
I'm going to have to go into the office Sunday to re-work our timeclock app because of this. The original developer that wrote it all in PHP attempted to be timezone neutral but screwed it up. He attempted to store date/time values in GMT but actually applied the TZ offset to the GMT value so if you're at -5 (EST) the value recorded is actually +5 hours. He managed to replicate the bug when retrieving the values so it was never noticed. Consequently my .NET app that writes to the same DB has to replicate that bug, until I fix the whole shebang.
Of course the whole thing always had the problem where if you're in DST (-4 for Eastern) and try and pull a report from a -5 period (standard time) the hours are off because it assumed the TZ offset was the current TZ offset.
-
I wish they'd just pick one or the other. I hate having change all the clocks.
-
Not a fan.
If I had to settle, then pick a damn time and stick with it. I hate changing clocks and adapting twice a year. I also want to know whatever happened to, "if extending DST doesn't show any monetary savings, we're going to go back to the old DST date." Damn lying government.
Regardless, I like bacon.
-
I don't like the problems it creates in software. It adds tons of complication and abstraction to something that should be straight forward. The gregorian calendar is bad enough without that complication.
-
How many pounds of bacon do you have?
jim
-
Blows. I have always hated it.
-
How many pounds of bacon do you have?
jim
Wait, what? How drunk are you, Jim? =D Or is this just thread drift about delicious bacon?
(https://armedpolitesociety.com/proxy.php?request=http%3A%2F%2Fi44.tinypic.com%2Fs42k5y.jpg&hash=361e9904d39e0614ac2111bf60ff7983d1f0c65b)
-
Wait, what? How drunk are you, Jim? =D Or is this just thread drift about delicious bacon?
How drunk? I'm not sure. I've only been drinking since the camshaft broke.
What was that? Ten hours ago? Yeah I might be well buzzed. Time for some bacon.
jim
-
I HATE IT!
Any questions? :angel:
-
Daylight Savings is bad, except when I happen to be on watch when we skip an hour. =D
-
Not a fan.
If I had to settle, then pick a damn time and stick with it. I hate changing clocks and adapting twice a year. I also want to know whatever happened to, "if extending DST doesn't show any monetary savings, we're going to go back to the old DST date." Damn lying government.
Regardless, I like bacon.
What he said.
-
I'm just ticked off that nobody's seriously studying the the impact of an extra hour of sunlight on the climate, and instead get all wrapped up in CO2 and fossil fuels etc. :mad:
oooooooh! Im stealing that for my facebook!
-
IVFABIC
-
Shouldn't you be coating the surface of a moon somewhere?
-
Only effect on me this time around is that instead of 9 hours ahead of home, only will be 8 hours. A lot of the rest of the world doesn't follow it so why in the hell should we.
-
I love it in the fall (YAY extra hour of sleep) I hate it in the spring (i have to get up an hour before I hate getting at! Grrrr)
Really hate it this time round. [ar15] is what the alarm clock is going to get in a few hours...
-
Shouldn't you be coating the surface of a moon somewhere?
Most rocky planets, actually.
-
I love it in the fall (YAY extra hour of sleep) I hate it in the spring (i have to get up an hour before I hate getting at! Grrrr)
Really hate it this time round. [ar15] is what the alarm clock is going to get in a few hours...
LOL!
-
I don't want an extra hour of daylight. I don't like daylight.
-
LOL!
If it wern't for the fact that the damn thing also happens to be my phone, my computer and my sole form of communitcation with the outside world, it would have gone blammo at 6:00 this morning.
Also, .45's are too damn loud this early in the morning. Maybe if I had a suppressor...
*yawn*
-
If it wern't for the fact that the damn thing also happens to be my phone, my computer and my sole form of communitcation with the outside world, it would have gone blammo at 6:00 this morning.
Also, .45's are too damn loud this early in the morning. Maybe if I had a suppressor...
*yawn*
A suppressed 45 is a dangerous thing to have around...not as bad as a 22 with a can...but close.
Bad thoughts begin, like "I bet I could shoot in here without my upstairs neighbors knowing" (in an apt)
-
DST is evil and unnecessary.....no wonder the gov't wants to continue using it....
-
A suppressed 45 is a dangerous thing to have around...not as bad as a 22 with a can...but close.
Bad thoughts begin, like "I bet I could shoot in here without my upstairs neighbors knowing" (in an apt)
Heh, .22 sub-sonic. Heh, this should be a lot quieter. Gets pistol, steps outside into urban night. Nope! Back inside, lights off.
-
Virtually all 22LR is subsonic out of a pistol. After much careful experimentation, I can confidently say that my p22/gemtech outback combo is subsonic (no bullet crack)...and quieter than most air rifles.
-
A suppressed 45 is a dangerous thing to have around...not as bad as a 22 with a can...but close.
Bad thoughts begin, like "I bet I could shoot in here without my upstairs neighbors knowing" (in an apt)
Mine is the raven sitting on the peak of my neighbors roof squawking it's head off. I look longingly at my suppressed .22 Savage mkII and sigh.
-
Benifits to living in BFE virginia is that there are no neighbors to PO.
However, first thing in the morning, groggy and without caffine in my system *BANG* is not something I can tolerate.
Then again, I can't really tolerate *beep beep beep* either...
-
How about "Beep-beep-beep-beep-beep-bee- BANG!" ?
Can that be tolerated? [popcorn] =D
-
"Year-round DST plus Double DST in summers for sunshine till 9 or 10 pm" FTW.
http://voices.washingtonpost.com/rawfisher/2009/03/its_time_for_double_daylight_s.html
-
I have to have an alarm clock that sounds like birds or some sort of slowly building alternate chimes. Damn buzzer makes me go tight in the chest. Some thing went off somewhere in retail land, sounded for all the world like a shipboard chemical alarm, not quite a PTSD deal but I really wanted that noise to stop.
-
Split the diff and stay with it.
-
What does the gubbermint do with all the daylight that we "save" ???
Why can't we use it during the winter when we need it? ;/
My guess is that they are selling it to South America >:D
-
I hate it. As a programmer it plays merry hob with every date/time storage system you use as soon as you try and go time-zone neutral.
I'm going to have to go into the office Sunday to re-work our timeclock app because of this. The original developer that wrote it all in PHP attempted to be timezone neutral but screwed it up. He attempted to store date/time values in GMT but actually applied the TZ offset to the GMT value so if you're at -5 (EST) the value recorded is actually +5 hours. He managed to replicate the bug when retrieving the values so it was never noticed. Consequently my .NET app that writes to the same DB has to replicate that bug, until I fix the whole shebang.
Of course the whole thing always had the problem where if you're in DST (-4 for Eastern) and try and pull a report from a -5 period (standard time) the hours are off because it assumed the TZ offset was the current TZ offset.
Never, ever, EVER store a timestamp as anything other than epoch time. Convert to human-readable format only when humans need to read it.
-
I love it, love it. In Michigan, on the west edge of est, we get daylight in the summer till nearly 10:30PM. I love it.
-
Never, ever, EVER store a timestamp as anything other than epoch time. Convert to human-readable format only when humans need to read it.
Uhm, that's exactly the kind of thing that produced the bug I've got to deal with. When I see "1823474550" in a DB table I have no idea what that means time-wise and I doubt you do too.
Storing time values like that makes it easy for the programmer to accidentally mask their bugs. If they accidentally shift things to +5 instead of GMT they won't notice if they make the same mistake pulling it back.
-
What does the gubbermint do with all the daylight that we "save" ???
You're supposed to keep that extra hour you get in the fall, so you can use it when we change back in the spring.
-
You're supposed to keep that extra hour you get in the fall, so you can use it when we change back in the spring.
I traded mine off for carbon credits.....
-
Storing time values like that makes it easy for the programmer to accidentally mask their bugs. If they accidentally shift things to +5 instead of GMT they won't notice if they make the same mistake pulling it back.
Epoch time is not dependent upon your time zone. It is defined as the number of seconds that have elapsed since 1970-01-01T00:00:00GMT. If a computer set to EST and a computer set to PST both store an epoch timestamp at the same time, the value will be the same in the database (assuming system clocks are accurate). Every programming language has easily-available (if not built-in) functions for retrieving the current epoch time and also for displaying a given epoch time value in human-readable format (for default or specified time zones). There is not two-way conversion, you simply insert the epoch time code into the database and when you want to print out your invoice or whatever, you print date($format, $time)
-
Storing time values like that makes it easy for the programmer to accidentally mask their bugs. If they accidentally shift things to +5 instead of GMT they won't notice if they make the same mistake pulling it back.
Why is this a problem? Just fix the code, and fix the data.
UPDATE db_table SET db_value = db_value - 18000;
Easy!
The point, as CNYCacher explained, is to use a timezone neutral timing standard. An absolute time, if you will. Leave the pesky human abstractions to the front end; the back end deals in absolute time from a fixed point.
-
I'm relieved...been putting off setting those pesky clocks back an hour, since last Fall.
-
Why is this a problem? Just fix the code, and fix the data.
UPDATE db_table SET db_value = db_value - 18000;
Easy!
Er, not that easy. The offset is different depending on the whether or not we were in DST.
Epoch time is not dependent upon your time zone. It is defined as the number of seconds that have elapsed since 1970-01-01T00:00:00GMT.
You know that, and I know that, but the original developer of my app didn't know that... so even though he was using the MySQL Unixtime date format he was still doing the TZ offset. So he actually shifted the stored values to +4 or +5 GMT.
And that's hard to spot when you're storing time as a long integer. It means nothing to us.
Now, when you store it as an actual DATETIME, you can read that. If you insert a record at 2012-03-13 1:00pm local time (-4 offset) and it shows up as 2012-03-13 9:00pm you know something is wrong with your code. Well, as long as you know what time it should be in GMT/UTC.
Even better, IMHO, is to store the local datetime value AND the current TZ offset. That way anybody pulling the data can convert from local time to GMT/UTC without looking up anything. You stored the offset for them. And replaying stuff in local time for the events is easy because there's no conversion. When you store in GMT/UTC without the offset the programmer has to reconstruct whatever (government) rules were in place for daylight savings at the time in your current timezone which 99.9% of the time is going to be the same as the place it was recorded except that your DST offset has about a 60 or 40-ish% chance of being wrong so you need to know what the offset was back then. And that means filtering the dates through a library that remembers what the old DST rules were.
I'm not even sure what my point was. I just hate DST and timezones in general as programmer and data warehousing guy. As a retailer I think DST is great though!
-
You and I are going to have to just agree to disagree on this one, Giga.
As far as fixing the code, you'll have to add a where clause with between ranges for the start and end dates of DST for each year back. Well, more specifically there are ranges of years that can be grouped, but I don't see this as being more then about a 2 hour ordeal to fix from what you've told us.
Of course, this is coming from someone who *still* hasn't fixed the 2106 problem with APS. :angel:
-
I love it, love it. In Michigan, on the west edge of est, we get daylight in the summer till nearly 10:30PM. I love it.
Agreed, but I wish it would stay as it is in the summer. I greatly prefer more daylight in the afternoon than in the morning.
Democrats love the spring jump though, because their food stamps for the week only have to last 167 hours, instead of 168.