Yes, it always strikes me as newbie amateur code when software uses timestamps to check for file modifications. I'm looking at you Xcode... I hit this problem once 10 years ago and learned the lesson ffs.
So what does make use then?
Falsehoods Programmers believe about Time
191–200 of 222 posts
Re: Falsehoods Programmers believe about Time
#192Yes, it always strikes me as newbie amateur code when software uses timestamps to check for file modifications. I'm looking at you Xcode... I hit this problem once 10 years ago and learned the lesson ffs.
So what does make use then?
Re: Falsehoods Programmers believe about Time
#193My recent favorites wrong assumptions: 1. The year is 2012. In Thailand, the year is 2555. In Malaysia, the year is 1433. 2. But surely that is not used on computers and the web? http://www.railway.co.th/home/Default.asp?lenguage=Eng (look on the right side: "booking can be until : 18/8/2555"
In North Korea it's 100 IIRC
Re: Falsehoods Programmers believe about Time
#194Earlier quoted context omitted.
IMHO you will change your tune with more time and experience; numerics are often more portable and unambiguous than string or serialized-object alternatives... e.g., if you pass around datetimes as "int64 count of 100-ns intervals since 1-1-1601 UTC" there is little opportunity for someone who doesn't know how to use it to get a quasi-usable yet incorrect datetime out of it. Also note, there are plenty of database sy…
There's a standard for that. ISO 8601. Use that. Don't make up your own.
The '100ns ticks' example is actually the Windows FILETIME, not my own invention. ISO 8601 is fine and dandy for stringified datetimes, although it's my position that strings open the door to more errors when consumed or produced by lazy/poor programmers.
Re: Falsehoods Programmers believe about Time
#195Earlier quoted context omitted.
Between 1582 and 1752 England had two different New Year's Days, January 1 and March 25, used for different purposes. The same day had different years depending on who you were talking to. See http://en.wikipedia.org/wiki/Dual_dating .
The tax year in UK still start/end on March 25th IIRC
6th April, actually.
Re: Falsehoods Programmers believe about Time
#196How about some calendaring issues I'm sure any Israeli is familiar with: 1. Weeks start on Monday. 2. Days begin in the morning. 3. Re: 2, holidays span an integer number of whole days. Explanations: 1: In Israel, the week starts on Sunday. Most programs have support for changing the "start of week day". Most programs. 2-3: In the Jewish calendar, the day starts when the moon comes out. This means that holidays that…
> In the Jewish calendar, the day starts when the moon comes out.
say what? afaik (speaking as a jew here), it's when the sun goes down. (moonrise, averaged over all time, happens at any point in the 24-hour cycle.)
possibly you're thinking of when (jewish calendar) months start?
Re: Falsehoods Programmers believe about Time
#19735. Two timezones that differ, will differ by an integer number of hours.
17% of the world's population lives in a single .5 timezone (https://en.wikipedia.org/wiki/Indian_Standard_Time), so i'd hope that one's not too widespread....
Re: Falsehoods Programmers believe about Time
#198I was reading this and realizing that he was mixing two very different things: design considerations and design errors. Treating every year as 365 days is a design error. Leap years will break it. "Timezones next to eachother don't require changes of more than 1 hr" might also doom that F22 flying across the international date line (ok, I am assuming that was more of a test assumption than a code assumption). On the…
> requiring that clocks be set to within, say, five minutes (Kerberos 5) is a design consideration. Right. I love this. You can't assume it unless you document it as a requirement and make someone else make it true for all the systems your software runs on. Never forget that specifications are a contract, an agreement entered into between the implementer and the user. If either side lets down their end, the agreement…
> Even if you have a mathematical proof that your software is correct, it's still only correct given certain assumptions taken as axioms in the proof. Violate those axioms and your software can't be held responsible.
"Beware of bugs in the above code; I have only proved it correct, not tried it." - knuth
Re: Falsehoods Programmers believe about Time
#199I work on a calendar application and I can attest to all kinds of issues dealing with time, dates, and time zones. It's very difficult to get right and most of the time we just hope that for our purposes it's close enough. A big issue is dealing with timezone conversions especially because different applications represent time zones with different english language versions of the names, like "US Mountain Standard Tim…
the "country/(city/region)" notation is from zoneinfo, the standard unix timezone system. "X standard time" (and "X daylight time") are the common names most people in america use when referring to timezones.
zoneinfo's form has the benefit of having a nice, unambiguous way to refer to the various daylight-saving time exceptions (arizona, indiana, hawaii, etc.).
recently i've seen huge timezone lists that basically throw in the kitchen sink--they'll have the entire zoneinfo set, the common american names, miscellaneous other common regional names (euro, australia, etc.) and raw whole-hour offsets as well. makes for a long drop-down to navigate....
Re: Falsehoods Programmers believe about Time
#200I assumed a year had 52 weeks. 2009 had 53.