Daylight Saving Time Code Woes

Post Reply
JTA
Commander
Posts: 3898
Joined: Sat Oct 13, 2012 4:04 pm

Daylight Saving Time Code Woes

Unread post by JTA »

I spent over an hour debugging this problem today, that wasn't a problem.

Long story short I'm working on this gannt chart type thing. Whenever I would drag a block to the first day of the week, Sunday, an extra hour would be added. I couldn't for the life of me figure it out. I dug deep down into the plugin I was using, jotted down a bunch of notes, until I inspected my date objects and noticed the following:

Thu Mar 12 2015 17:23:27 GMT-0400 (Eastern Daylight Time)
Sat Mar 08 2014 00:00:00 GMT-0500 (Eastern Standard Time)

Daylight saving time! Extra hour added for the time shift. AHHHHHHHHHHHHH!
You aren't doing it wrong if no one knows what you are doing.

User avatar
bannination
Captain
Posts: 5502
Joined: Sun Sep 16, 2012 7:58 am
Location: Hendersonville
Contact:

Re: Daylight Saving Time Code Woes

Unread post by bannination »

JTA wrote:I spent over an hour debugging this problem today, that wasn't a problem.

Long story short I'm working on this gannt chart type thing. Whenever I would drag a block to the first day of the week, Sunday, an extra hour would be added. I couldn't for the life of me figure it out. I dug deep down into the plugin I was using, jotted down a bunch of notes, until I inspected my date objects and noticed the following:

Thu Mar 12 2015 17:23:27 GMT-0400 (Eastern Daylight Time)
Sat Mar 08 2014 00:00:00 GMT-0500 (Eastern Standard Time)

Daylight saving time! Extra hour added for the time shift. AHHHHHHHHHHHHH!
Time and dates are the worst.... especially when dealing with international crap. Luckily I've avoided that kind of work so far....

JTA
Commander
Posts: 3898
Joined: Sat Oct 13, 2012 4:04 pm

Re: Daylight Saving Time Code Woes

Unread post by JTA »

bannination wrote:
JTA wrote:I spent over an hour debugging this problem today, that wasn't a problem.

Long story short I'm working on this gannt chart type thing. Whenever I would drag a block to the first day of the week, Sunday, an extra hour would be added. I couldn't for the life of me figure it out. I dug deep down into the plugin I was using, jotted down a bunch of notes, until I inspected my date objects and noticed the following:

Thu Mar 12 2015 17:23:27 GMT-0400 (Eastern Daylight Time)
Sat Mar 08 2014 00:00:00 GMT-0500 (Eastern Standard Time)

Daylight saving time! Extra hour added for the time shift. AHHHHHHHHHHHHH!
Time and dates are the worst.... especially when dealing with international crap. Luckily I've avoided that kind of work so far....
Yeah man tell me about it. I've been getting reaallll intimate with my dates here lately and doing some real nasty things with them that most would scoff and run away at. But sometimes you just gotta take a swig and hold your breath and get down and dirty and nasty and do what needs to be done for that pay check man.
You aren't doing it wrong if no one knows what you are doing.

Mr.B
A bad person.
Posts: 4891
Joined: Tue Jun 18, 2013 4:22 pm

Re: Daylight Saving Time Code Woes

Unread post by Mr.B »

bannination wrote: "Luckily I've avoided that kind of work so far...."
Yeah, me too. I found the answer to that dilemma though.... I change the time on ALL my clocks before I go to bed... :thumbup:

JTA
Commander
Posts: 3898
Joined: Sat Oct 13, 2012 4:04 pm

Re: Daylight Saving Time Code Woes

Unread post by JTA »

Mr.B wrote:
bannination wrote: "Luckily I've avoided that kind of work so far...."
Yeah, me too. I found the answer to that dilemma though.... I change the time on ALL my clocks before I go to bed... :thumbup:
I keep my clocks permanently on DST, that way I don't have to change any of them. When DST comes around again they read the right time and I no longer have to do the math in my head to figure out the true time.
You aren't doing it wrong if no one knows what you are doing.

Mr.B
A bad person.
Posts: 4891
Joined: Tue Jun 18, 2013 4:22 pm

Re: Daylight Saving Time Code Woes

Unread post by Mr.B »

JTA wrote: "I keep my clocks permanently on DST, that way I don't have to change any of them. When DST comes around again they read the right time and I no longer have to do the math in my head to figure out the true time."
I'm gonna be nice and not say anything about how that comment fits right in with your avatar.... :lol:

JTA
Commander
Posts: 3898
Joined: Sat Oct 13, 2012 4:04 pm

Re: Daylight Saving Time Code Woes

Unread post by JTA »

Mr.B wrote:
JTA wrote: "I keep my clocks permanently on DST, that way I don't have to change any of them. When DST comes around again they read the right time and I no longer have to do the math in my head to figure out the true time."
I'm gonna be nice and not say anything about how that comment fits right in with your avatar.... :lol:
Mr b are you making fun of the way I look? You know that's a real life pic of me right?
You aren't doing it wrong if no one knows what you are doing.

User avatar
bannination
Captain
Posts: 5502
Joined: Sun Sep 16, 2012 7:58 am
Location: Hendersonville
Contact:

Re: Daylight Saving Time Code Woes

Unread post by bannination »

Mr. B. just has no respect for other peoples feelings.

:mrgreen:

Mr.B
A bad person.
Posts: 4891
Joined: Tue Jun 18, 2013 4:22 pm

Re: Daylight Saving Time Code Woes

Unread post by Mr.B »

JTA wrote:"Mr b are you making fun of the way I look? You know that's a real life pic of me right?"
I'm biting my tongue over that "real life" thingy........ :-H
bannination wrote:"Mr. B. just has no respect for other peoples feelings." :mrgreen:
That's 'cause I don't go 'round feeling of other people... :wtf:

JTA
Commander
Posts: 3898
Joined: Sat Oct 13, 2012 4:04 pm

Re: Daylight Saving Time Code Woes

Unread post by JTA »

Mr.B wrote:
JTA wrote:"Mr b are you making fun of the way I look? You know that's a real life pic of me right?"
I'm biting my tongue over that "real life" thingy........ :-H

Please explain I do not get it.

Image

Are you jealous of my white-man fro?
You aren't doing it wrong if no one knows what you are doing.

Mr.B
A bad person.
Posts: 4891
Joined: Tue Jun 18, 2013 4:22 pm

Re: Daylight Saving Time Code Woes

Unread post by Mr.B »

JTA wrote:
Mr.B wrote:
JTA wrote:"Mr b are you making fun of the way I look? You know that's a real life pic of me right?"
I'm biting my tongue over that "real life" thingy........ :-H
Please explain I do not get it.
Are you jealous of my white-man fro?
You know...that "get a real life" saying? :wave:
No, I'm not jealous...you like mine?



Image

JTA
Commander
Posts: 3898
Joined: Sat Oct 13, 2012 4:04 pm

Re: Daylight Saving Time Code Woes

Unread post by JTA »

Mr.B wrote:
JTA wrote:
Mr.B wrote:
JTA wrote:"Mr b are you making fun of the way I look? You know that's a real life pic of me right?"
I'm biting my tongue over that "real life" thingy........ :-H
Please explain I do not get it.
Are you jealous of my white-man fro?
You know...that "get a real life" saying? :wave:
No, I'm not jealous...you like mine?



Image
Most beautiful white-man fro I've seen to date, Even better than Messiah Marcolin's.

Another impressive white-man fro:

Image
You aren't doing it wrong if no one knows what you are doing.

User avatar
rstrong
Captain
Posts: 5889
Joined: Thu Oct 25, 2012 9:32 am
Location: Winnipeg, MB

Re: Daylight Saving Time Code Woes

Unread post by rstrong »

JTA wrote:Daylight saving time! Extra hour added for the time shift. AHHHHHHHHHHHHH!
It was even worse when they changed the dates for daylight savings time a few years back.

From Falsehoods programmers believe about time
All of these assumptions are wrong
1.There are always 24 hours in a day.
2.Months have either 30 or 31 days.
3.Years have 365 days.
4.February is always 28 days long.
5.Any 24-hour period will always begin and end in the same day (or week, or month).
6.A week always begins and ends in the same month.
7.A week (or a month) always begins and ends in the same year.
8.The machine that a program runs on will always be in the GMT time zone.
9.Ok, that’s not true. But at least the time zone in which a program has to run will never change.
10.Well, surely there will never be a change to the time zone in which a program has to run in production.
11.The system clock will always be set to the correct local time.
12.The system clock will always be set to a time that is not wildly different from the correct local time.
13.If the system clock is incorrect, it will at least always be off by a consistent number of seconds.
14.The server clock and the client clock will always be set to the same time.
15.The server clock and the client clock will always be set to around the same time.
16.Ok, but the time on the server clock and time on the client clock would never be different by a matter of decades.
17.If the server clock and the client clock are not in synch, they will at least always be out of synch by a consistent number of seconds.
18.The server clock and the client clock will use the same time zone.
19.The system clock will never be set to a time that is in the distant past or the far future.
20.Time has no beginning and no end.
21.One minute on the system clock has exactly the same duration as one minute on any other clock
22.Ok, but the duration of one minute on the system clock will be pretty close to the duration of one minute on most other clocks.
23.Fine, but the duration of one minute on the system clock would never be more than an hour.
24.You can’t be serious.
25.The smallest unit of time is one second.
26.Ok, one millisecond.
27.It will never be necessary to set the system time to any value other than the correct local time.
28.Ok, testing might require setting the system time to a value other than the correct local time but it will never be necessary to do so in production.
29.Time stamps will always be specified in a commonly-understood format like 1339972628 or 133997262837.
30.Time stamps will always be specified in the same format.
31.Time stamps will always have the same level of precision.
32.A time stamp of sufficient precision can safely be considered unique.
33.A timestamp represents the time that an event actually occurred.
34.Human-readable dates can be specified in universally understood formats such as 05/07/11.
And in part two, once people started commenting on the original list:
All of these assumptions are wrong
1.The offsets between two time zones will remain constant.
2.OK, historical oddities aside, the offsets between two time zones won’t change in the future.
3.Changes in the offsets between time zones will occur with plenty of advance notice.
4.Daylight saving time happens at the same time every year.
5.Daylight saving time happens at the same time in every time zone.
6.Daylight saving time always adjusts by an hour.
7.Months have either 28, 29, 30, or 31 days.
8.The day of the month always advances contiguously from N to either N+1 or 1, with no discontinuities.
9.There is only one calendar system in use at one time.
10.There is a leap year every year divisible by 4.
11.Non leap years will never contain a leap day.
12.It will be easy to calculate the duration of x number of hours and minutes from a particular point in time.
13.The same month has the same number of days in it everywhere!
14.Unix time is completely ignorant about anything except seconds.
15.Unix time is the number of seconds since Jan 1st 1970.
16.The day before Saturday is always Friday.
17.Contiguous timezones are no more than an hour apart. (aka we don’t need to test what happens to the avionics when you fly over the International Date Line)
18.Two timezones that differ will differ by an integer number of half hours.
19.Okay, quarter hours.
20.Okay, seconds, but it will be a consistent difference if we ignore DST.
21.If you create two date objects right beside each other, they’ll represent the same time. (a fantastic Heisenbug generator)
22.You can wait for the clock to reach exactly HH:MM:SS by sampling once a second.
23.If a process runs for n seconds and then terminates, approximately n seconds will have elapsed on the system clock at the time of termination.
24.Weeks start on Monday.
25.Days begin in the morning.
26.Holidays span an integer number of whole days.
27.The weekend consists of Saturday and Sunday.
28.It’s possible to establish a total ordering on timestamps that is useful outside your system.
29.The local time offset (from UTC) will not change during office hours.
30.Thread.sleep(1000) sleeps for 1000 milliseconds.
31.Thread.sleep(1000) sleeps for >= 1000 milliseconds.
32.There are 60 seconds in every minute.
33.Timestamps always advance monotonically.
34.GMT and UTC are the same timezone.
35.Britain uses GMT.
36.Time always goes forwards.
37.The difference between the current time and one week from the current time is always 7 * 86400 seconds.
38.The difference between two timestamps is an accurate measure of the time that elapsed between them.
39.24:12:34 is a invalid time
40.Every integer is a theoretical possible year
41.If you display a datetime, the displayed time has the same second part as the stored time
42.Or the same year
43.But at least the numerical difference between the displayed and stored year will be less than 2
44.If you have a date in a correct YYYY-MM-DD format, the year consists of four characters
45.If you merge two dates, by taking the month from the first and the day/year from the second, you get a valid date
46.But it will work, if both years are leap years
47.If you take a w3c published algorithm for adding durations to dates, it will work in all cases.
48.The standard library supports negative years and years above 10000.
49.Time zones always differ by a whole hour
50.If you convert a timestamp with millisecond precision to a date time with second precision, you can safely ignore the millisecond fractions
51.But you can ignore the millisecond fraction, if it is less than 0.5
52.Two-digit years should be somewhere in the range 1900-2099
53.If you parse a date time, you can read the numbers character for character, without needing to backtrack
54.But if you print a date time, you can write the numbers character for character, without needing to backtrack
55.You will never have to parse a format like ---12Z or P12Y34M56DT78H90M12.345S
56.There are only 24 time zones
57.Time zones are always whole hours away from UTC
58.Daylight Saving Time (DST) starts/ends on the same date everywhere
59.DST is always an advancement by 1 hour
60.Reading the client’s clock and comparing to UTC is a good way to determine their timezone
61.The software stack will/won’t try to automatically adjust for timezone/DST
62.My software is only used internally/locally, so I don’t have to worry about timezones
63.My software stack will handle it without me needing to do anything special
64.I can easily maintain a timezone list myself
65.All measurements of time on a given clock will occur within the same frame of reference.
66.The fact that a date-based function works now means it will work on any date.
67.Years have 365 or 366 days.
68.Each calendar date is followed by the next in sequence, without skipping.
69.A given date and/or time unambiguously identifies a unique moment.
70.Leap years occur every 4 years.
71.You can determine the time zone from the state/province.
72.You can determine the time zone from the city/town.
73.Time passes at the same speed on top of a mountain and at the bottom of a valley.
74.One hour is as long as the next in all time systems.
75.You can calculate when leap seconds will be added.
76.The precision of the data type returned by a getCurrentTime() function is the same as the precision of that function.
77.Two subsequent calls to a getCurrentTime() function will return distinct results.
78.The second of two subsequent calls to a getCurrentTime() function will return a larger result.
79.The software will never run on a space ship that is orbiting a black hole.

JTA
Commander
Posts: 3898
Joined: Sat Oct 13, 2012 4:04 pm

Re: Daylight Saving Time Code Woes

Unread post by JTA »

rstrong wrote:34.Human-readable dates can be specified in universally understood formats such as 05/07/11.
I made this mistake. Javascript for the most part is cool with a string with the timezone in it, so if you convert the date string to a Date object via new Date(<string>), everything is dandy... except if that string contains a timezone for something other than a US timezone. I can't recall what standard the date string was formatted in, maybe it was just some random-ass format whoever wrote the servlet decided to return... but anyway, if the server was running in a timezone outside the US, my stuff would not work at all. OoooOOooOooOoops :( Worked just fine with a US timezone, which really is the only timezone that should matter because Merica > Universe, as everyone already knows.
You aren't doing it wrong if no one knows what you are doing.

Mr.B
A bad person.
Posts: 4891
Joined: Tue Jun 18, 2013 4:22 pm

Re: Daylight Saving Time Code Woes

Unread post by Mr.B »

Maybe you'll wanna figure this one out......

Daylight-Saving Causes Twin Arrival Pickle...


Cary, N.C. — Everyone knows the pecking order in a family has everything to do with age. The oldest sibling usually rules the roost.
But what if you get cheated out of the title because of Daylight Saving Time?

Peter Sullivan Cirioli was dubbed "Baby A" at WakeMed Cary when he arrived early Sunday morning.

Image

“Yes, Peter was born first, it was at 1:32 a.m.,” mother Laura Cirioli said.

Thirty-four minutes later, Peter's twin sister, Allison Raye Cirioli, known as "Baby B," made her entrance into the world.

Because of Daylight Saving Time, Allison's time of birth was 1:06 a.m., which makes her 26 minutes older than her brother even though he was born first.

“We just never even thought about it until after he was born and then we realized it was going to happen.
It was really kind of amazing,” Laura Cirioli said.

The proud mother and father said they don't really care who was born first, they are just glad to have two healthy babies.
They do suspect the daylight savings predicament will be fodder for sibling rivalry.

“We'll let them work that out between themselves. I don't want to get into the middle of it,” Jason Cirioli said.

Post Reply