Do you aware of Y2K38?

Okay let me first tell what is the term Y2K38 or Unix Millennium bug or year 2038 problem: Well it is a some kind of computer programming problem with date (something similar like Y2K), says that all programs and software are going to crash on near or after 2038. You will find a Wikipedia definition here. Okay look at some php code and its output:

$timestamp=mktime(0, 0, 0, 01 , 01, 2009);
echo date("F j, Y, g:i a",$timestamp);   // January 1, 2009, 12:00 am

Well output shows expected result. But notice this code now:

$timestamp=mktime(0, 0, 0, 01 , 01, 2039);
echo date("F j, Y, g:i a",$timestamp);  //January 1, 1970, 7:00 am

Yes output is little shocking. This is what they are calling Y2K38. I think we don’t need to worry about it too much. We still have enough time to solve this.  The code above is tested in php(5.2.9) language. I also tested the same thing in java and there is no such problem i found yet (yes java is great!!! :D).

Calendar cal=Calendar.getInstance();
cal.set(2059,11,1,0,0,0);
Date date=cal.getTime();
String output;
DateFormat df=DateFormat.getDateInstance(DateFormat.FULL,Locale.ROOT);
output=df.format(date);
System.out.println(output); //Monday, December 1, 2059

notice input and output(shows as expected). Yes we don’t need to worry about it. If we manage to survive until 2038 we will definitely have a solution by then.
Continue reading “Do you aware of Y2K38?”

Official PHP Coding Standards

Download the php official coding standard documentation in pdf format from here

This file lists several standards that any programmer, adding or changing code in PHP, should follow. Since this file was added at a very late stage of the development of PHP v3.0, the code base does not (yet) fully follow it, but it’s going in that general direction. Since we are now well into the version 4 releases, many sections have been recoded to use these rules.

Software Lifecycle

Software doesn’t just appear on the shelves by magic. That program shink-wrapped inside the box along with the indecipherable manual and 12-paragraph disclaimer notice actually came to you by way of an elaborate path, through the most rigid quality control on the planet. Here, shared for the first time with the general public, are the inside details of the program development cycle.

1. Programmer produces code he believes is bug-free.

2. Product is tested. 20 bugs are found.

3. Programmer fixes 10 of the bugs and explains to the testing department that the other 10 aren’t really bugs.

4. Testing department finds that five of the fixes didn’t work and discovers 15 new bugs.

5. See 3.

6. See 4.

7. See 5.

8. See 6.

9. See 7.

10. See 8.

11. Due to marketing pressure and an extremely pre-mature product announcement based on over-optimistic programming schedule, the product is released.

12. Users find 137 new bugs.

13. Original programmer, having cashed his royalty check, is nowhere to be found.

14. Newly-assembled programming team fixes almost all of the 137 bugs, but introduce 456 new ones.

15. Original programmer sends underpaid testing department a postcard from Fiji. Entire testing department quits.

16. Company is bought in a hostile takeover by competitor using profits from their latest release, which had 783 bugs.

17. New CEO is brought in by board of directors. He hires programmer to redo program from scratch.

18. Programmer produces code he believes is bug-free. —-

Top 20 programers excuses

The Top 20 replies by programmers when their programs do not work:

20. “That’s weird…”
19. “It’s never done that before.”
18. “It worked yesterday.”
17. “How is that possible?”
16. “It must be a hardware problem.”
15. “What did you type in wrong to get it to crash?”
14. “There is something funky in your data.”
13. “I haven’t touched that module in weeks!”
12. “You must have the wrong version.”
11. “It’s just some unlucky coincidence.”
10. “I can’t test everything!”
9. “THIS can’t be the source of THAT.”
8. “It works, but it hasn’t been tested.”
7. “Somebody must have changed my code.”
6. “Did you check for a virus on your system?”
5. “Even though it doesn’t work, how does it feel?
4. “You can’t use that version on your system.”
3. “Why do you want to do it that way?”
2. “Where were you when the program blew up?”

And the Number One reply by programmers when their programs don’t work:
1. “It works on my machine.” 😉