Four days ago I managed to get my new phone soaked in water for a few minutes. The phone was at standby mode, but was not switched off at the time. I grabbed the phone and pressed the power key to turn it off (an unnecessary wrong move!). No greeting message, the phone was dead. I yanked the battery off then shook the phone as hard as I can.
Google search yielded quite a few helpful links for how to fix a water-damaged phone [1-2]. I let a fan blow at the phone for four hours; then buried it overnight in a box of white rice. The second day, I bought two bags of Japanese seaweed soup base just to get the two phone-size packs of lime desiccant inside. Then I let a hair dryer blow at the phone with warm air at a safe distance; sandwiched the phone with the two lime packs, seal them in a small airtight food storage container box. Waited and waited …
Recommendation on the waiting period varies, ranging from 24 hours to 3 days. As a replacement of my phone will cost $500, I waited for four full days. Every day, I hair-dried the lime packs, refilled the box with dry air, prayed a little, and killed the growing anxiety to test the phone. All efforts paid off and the phone resurrected at the end!
What have been equally educational is to learn how carriers have embedded “liquid damage indicators (LDI)” to prevent fraud claims on such devices. Basically the indicator contains a layer of red dye is beneath a layer of white paper, when moisturized, the white paper turns into red and the carrier can easily void any warranty based on the mark. People get “creative” in bleaching the indicator back to white [3]. This is certainly detectable, as bleached indicator no longer turns red when moisturized again, plus there could be other hidden indicators you may not see until you take the phone apart. So the best advice definitely is to be honest here. Nevertheless I need to check if my phone was enrolled in any insurance plan.
1. http://www.wikihow.com/Save-a-Wet-Cell-Phone
2. http://www.popularmechanics.com/technology/how-to/tips/4269047
3. http://www.instructables.com/id/Turn-Your-Cell-Phones-quotI-Got-Wetquot-Indic/
Sunday, November 28, 2010
Sunday, May 2, 2010
Save the Daylight Saving Time (DST)
Getting home after work can be a different experience in the spring versus in the fall. As now the sun still overlooks the horizon at 6pm, I cannot help trimming my garden, while the dinner is being fixed. When the Daylight Saving Time (DST) just goes into its annual hibernation, driving home in the gloominess has the word "overwork" written all over my body.
Many funny things happen during the on/off switch of the DST. Do you know trains all stopped at 2am for an hour in the spring, but tries to run crazy in the fall because it is suddenly 1 hour behind schedule [1]. We can laugh about this somewhat silly solution to the train problem, but we ought to get serious about how to guard our savings in the bank during the switch of DST.
Say you withdraw $100 at 1:30am; the clock is set back to 1am in 30min; you then withdraw another $100 at the second 1:30am. Can you walk into the bank in the morning and claim you really only did one withdraw and ask for another $100 back into your checking account? If an ATM associates the two transactions with the same text string “Mar 14, 2001, 1:30am”, the bank indeed will have a hard time proving the duplicate withdrawn are not their mistake. We all know there is no free lunch, so how this works?
Computes all use UNIX time [2], i.e., time is not memorized as a text string, but rather as a number. The first “Mar 14, 2001, 1:30am” is recorded as the number 1268530200, i.e., the number of seconds between that precise moment and Jan 1, 1970, 12:00am; the second “Mar 14, 2001, 1:30am” is recorded as 1268533800 (3600 larger than the first one). The banking system has no trouble telling these two transactions apart; software only relies on the UNIX time for all its computing logic, and only use the text format for sole display purpose.
So programmers need to be aware, if you export those transactions from database into a text file, you will only get their text representations and which might well trigger some serious bugs in your data analysis code.
“Spring forward and fall back” is just a zeroth-order approximate to catch up with the sunrise and sunset schedule. With computers and cell phones totally capable of automatically syncing themselves with the Internet, we are well prepared for a DST that is much less disturbance to our daily routines. Here is my idea: the one-hour shift (a step function) during half a year period can be better modeled with a saw tooth function over a year (see figure), i.e., the clock moves forward only 1/3 minute per day in spring and summer, then moves backward 1/3 minute per day day in fall and winter. With such tiny adjustment, the train will run as it should be and we can drive home with the sun positioned where it should be every day.
P.S. If you think a change in a fraction of an hour is hard to accept, you may want to check out the current time in India (http://www.worldtimeserver.com/current_time_in_IN.aspx). It caught me in surprise two weeks ago that the time difference between India and us are 12 hours and 30 minutes!
Many funny things happen during the on/off switch of the DST. Do you know trains all stopped at 2am for an hour in the spring, but tries to run crazy in the fall because it is suddenly 1 hour behind schedule [1]. We can laugh about this somewhat silly solution to the train problem, but we ought to get serious about how to guard our savings in the bank during the switch of DST.
Say you withdraw $100 at 1:30am; the clock is set back to 1am in 30min; you then withdraw another $100 at the second 1:30am. Can you walk into the bank in the morning and claim you really only did one withdraw and ask for another $100 back into your checking account? If an ATM associates the two transactions with the same text string “Mar 14, 2001, 1:30am”, the bank indeed will have a hard time proving the duplicate withdrawn are not their mistake. We all know there is no free lunch, so how this works?
Computes all use UNIX time [2], i.e., time is not memorized as a text string, but rather as a number. The first “Mar 14, 2001, 1:30am” is recorded as the number 1268530200, i.e., the number of seconds between that precise moment and Jan 1, 1970, 12:00am; the second “Mar 14, 2001, 1:30am” is recorded as 1268533800 (3600 larger than the first one). The banking system has no trouble telling these two transactions apart; software only relies on the UNIX time for all its computing logic, and only use the text format for sole display purpose.
So programmers need to be aware, if you export those transactions from database into a text file, you will only get their text representations and which might well trigger some serious bugs in your data analysis code.
“Spring forward and fall back” is just a zeroth-order approximate to catch up with the sunrise and sunset schedule. With computers and cell phones totally capable of automatically syncing themselves with the Internet, we are well prepared for a DST that is much less disturbance to our daily routines. Here is my idea: the one-hour shift (a step function) during half a year period can be better modeled with a saw tooth function over a year (see figure), i.e., the clock moves forward only 1/3 minute per day in spring and summer, then moves backward 1/3 minute per day day in fall and winter. With such tiny adjustment, the train will run as it should be and we can drive home with the sun positioned where it should be every day.
P.S. If you think a change in a fraction of an hour is hard to accept, you may want to check out the current time in India (http://www.worldtimeserver.com/current_time_in_IN.aspx). It caught me in surprise two weeks ago that the time difference between India and us are 12 hours and 30 minutes!
[1] http://www.webexhibits.org/daylightsaving/k.html
[2] http://en.wikipedia.org/wiki/Unix_time
Subscribe to:
Posts (Atom)