25 ms·
Falsehoods Programmers believe about Time
- cpeterso 14y agoAlso, time is unidirectional.
- tomjen3 14y agoWell time would be unidirectional, right? The computer clock might not be.
- zanny 14y agoOoooh, nerd time! If you are moving faster than the speed of light, you are perceiving whatever you are moving away from in reverse, because the light you are seeing was generated before when you left. (you are passing into light that is older than the light you started with). In terms of space-time, you would then be going backwards in time, if your point of reference for time was the Earth (and hint, given that we have all these nuanced time thingamajigs, it is)
- mooism2 14y agoIf you are moving faster than the speed of light, our understanding of physics is wrong and we can't make any sensible predictions.
- DanWaterworth 14y agoI think this would be better stated as, "the system clock increases monotonically".
- saraid216 14y agoCan someone explain #1? I suspect it has to do with crossing time zones?
- moskie 14y agoDay light savings transition days. When you skip ahead, that day has 23 hours in it. When you fall back, it has 25.
- mbrubeck 14y agoAlso leap seconds: https://en.wikipedia.org/wiki/Leap_second https://en.wikipedia.org/wiki/Leap_second
- JoshTriplett 14y agoAlso, any other change to the system clock. NTP will either slew or step the system clock to keep it synchronized with the upstream time source. And the user can explicitly set the clock, as well. See also assumptions 9 and 10.
- deleted 14y ago[deleted]
- deleted 14y ago[deleted]
- malkia 14y agoWhat moskie explained, but got me thinking - if somehow your laptop always synchronizes with the current zone, and you are in a airplane flying east->west, or west->east?
- baddox 14y agoWho believes these things? February is always 28 days long? Any 24-hour period will always begin and end in the same day (or week, or month)? A week always begins and ends in the same month?
- sp332 14y agoHe's talking about test code. So if those test cases are missing, but the programmer thinks the tests are thorough, then it looks like the programmer believes those things (or forgot that they weren't true).
- DougBTX 14y agoA bad test might boil down to, assert(month(now()) == month(now() + 24.hours)) then fail from time to time.
- maggit 14y agoI thought about the same thing. I choose to read the title as "Falsehoods programmers seem to believe about time". Or "act as if they believe" in place of "seem to believe". I can easily imagine somebody introducing a bug that relies on a 24 hour period ending in the same month as it began.
- gms7777 14y agoPerhaps the accurate title is "Assumptions programmers make about time"
- antidoh 14y agoBugs happen. Especially thoughtless ones. The title might better have been "Things programmers have tried to do with time."
- sp332 14y agoAbout #7: doesn't a month always end in the same year it started?
- tomjen3 14y agoWell I guess it is possible if you used some Chinese or Jewish calendar or something like that. But at least in the western system it shouldn't be possible to it to span years.
- stan_rogers 14y agoThe way you're thinking about it, yes -- but the passage of a month may take you from December the [mumbleth] to January the [mumbleth], which are in different years. For some strange reason, code in the wild doesn't always account for that, so the due date for an item may well be eleven months before the request was entered.
- hcarvalhoalves 14y agoI like to call this kind of bug "New Year's Wake-up Call from Hell".
- sses 14y agoOne I caught recently: The difference between the current time and one week from the current time is not always 7 * 86400 seconds. By noticing an automated test that failed 2 weeks out of the year.
- jes5199 14y agoI think every test suite has tests that only fail right around the start and end of daylight savings time.
- NoahSussman 14y agoIf the tests are failing because the production code is confused about daylight savings time, then you may have a serious problem. If on the other hand it's just the test code that's flaky, usually such problems can be alleviated by refactoring such that one passes the time function as a parameter. This is in preference to hard-coding calls to the system time in test, which imho one should never do. Once an arbitrary time function can be passed as a parameter, one can provide a mock or fake system clock for test purposes. Ideally one would still want to test under daylight savings' conditions. But at the least this approach leaves one in a place where one can test the common 24-hours-in-a-day case without having the tests spuriously fail two days out of every year.
- Ralith 14y agoOne of my favorites, encountered in the wild: Your system will never need to handle a time before 1970.
- hartez 14y agoRan into a similar one about ten years ago; a medical records system with the assumption that you wouldn't need dates before 1/1/1900. You know who goes to the doctor a lot? Centegenarians.
- arohner 14y ago35. Two timezones that differ, will differ by an integer number of hours.
- aardvark179 14y ago36. Two timezones that differ will differ by an integer number of half hours. 37. Okay, quarter hours. 38. Okay, seconds, but it will be a consistent difference if we ignore DST.
- bazzargh 14y ago39. If you create two date objects right beside each other, they'll represent the same time. (a fantastic Heisenbug generator) 40. You can wait for the clock to reach exactly HH:MM:SS by sampling once a second.
- eblume 14y agoI'm not sure this counts as a constructive comment, but an interesting anecdote anyway - an early coding partner of mine once wrote a procedure he expected to run once exactly every second by continuously polling the time in a while/do_nothing loop until exactly one second had passed. It took some convincing to get him to accept that try as he might, it was very unlikely that "==" was what he wanted there. The best part was that this was in Javascript (and obviously he was not using a timeout). The entire page would lock up while it waited for the second to elapse. He never even figured out the obvious usability concern because he was so confounded by the fact that the procedure wasn't getting called after a second had passed. Ok, to be fair, it was a freshman year programming class - not an unexpected or even unusual mistake. But it gave me a chuckle just now remembering it.
- gbog 14y agoIn the same vein I can bet I have seen at last 5 implementation of date diffing using string representation.
- 14y ago
- apaprocki 14y agoSometimes time is simplified on purpose: 15.9.1.2 Day Number and Time within Day # Ⓣ A given time value t belongs to day number Day(t) = floor(t / msPerDay) where the number of milliseconds per day is msPerDay = 86400000 http://es5.github.com/#x15.9.1.2 http://es5.github.com/#x15.9.1.2
- arohner 14y ago36. GMT and UTC are the same timezone.
- TazeTSchnitzel 14y ago36b. Britain uses GMT. Not true, we use BST (British Summer Time) during the summer.
- tomjen3 14y agoIf you really want to stress test time handling code, try to get it to accept Feburary 29, 1900 and Feburary 29, 2000. The first doesn't exist but the second does. But really, with regards to time use whatever library came with you programming language.
- grimlck 14y agoThat will stress it a bit, but to really torture it, see if it accepts 2012 June 30 23:59:60
- brazzy 14y agoOr June 1st 1905 00:02:00 in Singapore.
- aurelianito 14y agoI had to google this one. http://www.timeanddate.com/worldclock/clockchange.html?n=236&year=1905 http://www.timeanddate.com/worldclock/clockchange.html?n=236...
- hcarvalhoalves 14y agoNow that's just mean! ;)
- rplnt 14y agoWell, you don't know if 31.12.2015 will have a 23:59:60 or no. These seconds are announced just prior to being added, the system couln't possibly know it.
- dredmorbius 14y agoObviously no. That's after the Mayapocolypse.
- obtu 14y agoJune is already decided. We'll know either way about the December second when the next bulletin C is published, sometime next July: http://hpiers.obspm.fr/iers/bul/bulc/ http://hpiers.obspm.fr/iers/bul/bulc/
- keltex 14y ago35. There are years past 2079. SQL Server smalldatetime only goes up to June 6, 2079
- apaprocki 14y agoChecking the terminal, I don't see any corporate bonds maturing in 2079 yet. But I do see a handful in every year >= 2070 and <= 2077. So maybe a few more years and some people / firms will start hitting bugs...
- brazzy 14y agoAnd it doesn't even mention all the bizarre things that have been done (for reasons good and bad) to time by various governments. Like adjusting from local solar time to standard GMT offset timezones (which involves skipping a given number of minutes and seconds or having them twice). Or introducing/abolishing/moving around daylight savings time. Or "super daylight savings time" with a 2 hour offset. Or moving from one side of the international date line to the other. And of course the real biggie: the Gregorian calendar reform that various countries adopted at different times between 1582 and the 1920s, skipping between 10 and 13 days depending on when they adopted it.
- crazygringo 14y agoMy favorite is when Daylight Savings Time started after an election in Brazil, but before the date for the election runoffs. Turned out the voting machines couldn't be changed to handle the time change. Solution? They just pushed back the date when DST started until after the runoffs. http://statoids.com/tbr.html http://statoids.com/tbr.html -- "Note that the government frequently changes its mind [about DST] at the last minute."
- yxhuvud 14y agohttps://en.wikipedia.org/wiki/Swedish_calendar https://en.wikipedia.org/wiki/Swedish_calendar is my personal favorite when it comes to the transition to gregorian.
- snprbob86 14y agoYeah, this list is woefully incomplete. Here's another good read: http://naggum.no/lugm-time.html http://naggum.no/lugm-time.html
- prehensile 14y agoOh man, I read that article years ago, lost the link and have been unable to find it since. Thanks! Any technical document which starts with "The measurement of time has a very long history, dating back to the first records of human civilization" and has a section titled "Political Time" gets a special place in my heart.
- apaprocki 14y ago39. The next day after 3 Sep 1752 is 4 Sep 1752.
- jamesgeck0 14y ago40. There was a 3 Sept 1752.
- aardvark179 14y agoI love that people in this thread think the adoption of the Gregorian calendar happened on a single date, it's way more complex than that.
- zipdog 14y agoIn Sweden there was a 30th February 1712
- rmc 14y agoIn the British Empire/UK.
- crisnoble 14y agoIf only someone would come up with a standard time format, surely that would solve all issues... In all seriousness time-stamps are some of the most annoying things to compare ever.
- kstenerud 14y agohttp://xkcd.com/927/ http://xkcd.com/927/
- aliguori 14y agoThe comment about KVM in CentOS is probably inaccurate--not sure what it's referring to. In the 5.4-ish time scale, there were a lot of clock related problems. One of them had to do with frequency scaling... PCs have many time sources. The processor has it's own internal clock that ticks at a very fast rate (nanoseconds). There's the wallclock time which ticks at a slow rate (seconds). The internal clock starts at 0 when the system boots so it can't be used for wallclock time without adjustment. Some Operating Systems (like Linux), get the boot time from the real time clock (slow tick rate) but then compute the current time by adding the CPU internal clock to it. The CPU internal clock (TSC) can be wildly inaccurate for various reasons. One of them is frequency scaling which actually changes the frequency of the TSC dynamically. Unfortunately, if you're changing the frequency of the TSC on the host, guests that are running and accessing the TSC directly don't realize this has happened. So if you scale the TSC frequency by 50%, time starts moving 50% more slowly. BIOS can also scale processor speed on some servers without the OS knowing which can lead to the same problem on bare metal. More modern processors now have fixed TSC frequencies and KVM now has a paravirtual clock source both which address this problem. BTW, Windows does not use the TSC as a time source so Windows typically won't have this problem (although it has other problems). Time keeping in virtualization is fun :-)
- hcarvalhoalves 14y ago35. People will just assume all APIs and standard libs that deal with dates are sane Adobe managed to build a pretty shitty Date object for ActionScript that takes days as a 1-indexed parameter, but months as 0-indexed. Hopefully ActionScript is not used in banking [1] [1] http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/Date.html#Date() http://help.adobe.com/en_US/FlashPlatform/reference/actionsc...
- frankc 14y agoThis is not that insane, or at least relatively insane, because this matches the behavior of localtime(). I have heard the reason for using a 0-indexed month is for the convenience of mapping to an enum of month names.
- sk5t 14y agoIMHO a default month of January makes rather little sense, and would tend to facilitate subtle bugs... it seems you'd want the user to specify a month always, or maybe have a default of "indeterminate" or "Nevember"; the first position of an enum is very often the "nothing" case.
- DanWaterworth 14y agoHow about, "the difference between two timestamps is an accurate measure of the time that elapsed between them".
- morsch 14y agoWhat's wrong about that? Numerical issues due to the truncation (ie 2500ms → 2s) and subsequent subtraction? Leap seconds? Anything else?
- yxhuvud 14y agoMeasurement error, and the fact that the timestamps may not be taken on the same machine.
- SCdF 14y agoIt isn't? Can you explain that in a bit more detail?
- brk 14y agoSome examples that come to mind: 1) You're (possibly) assuming that both timestamps come from the same machine. They could be from two machines (Server timestamps a transaction start, client timestamps the end.) Clocks are not accurate, so the delta time is not correct. 2) Time A is before a DST change forward or back, Time B is after. Delta would be wrong by +/- 1 hour (assuming all other factors are tracking with accuracy. 3) Both times are taken on the same machine, but far enough apart that clock drift plays a factor. 4) Both times are taken on the same machine, but an ntptimesync cron job kicked off in between them and adjusted the system clock.
- icehawk 14y ago#4 is why you really should be using ntpd(8): after syncronization, NTP will try to slew the clock if the difference is less than 128ms, step it if it's offset is between 128ms and 1000ms, and will exit with an error if the offset changes to be greater than 1000ms.
- efnx 14y agoWhat about time can you depend on?
- jhawk28 14y agoYou can't. Time is a completely relative concept. If you expect order, use a sequence.
- avstraliitski 14y agoOrder isn't scalable.
- efnx 14y agoExactly.
- psykotic 14y agoObLink: Erik Naggum's The Long, Painful History of Time (http://naggum.no/lugm-time.html http://naggum.no/lugm-time.html)
- ColinWright 14y agoI've been on an airplane (on the flight deck - pre 2001) watching the sun rise in the West. Sometimes local time runs backwards.
- jcarreiro 14y agoSo, were you on the Concorde, or was it a Tu-144?
- gregholmberg 14y agoThe terminator is only that fast near the equator. Further north, " ... it is possible to walk faster than the terminator at the poles, near to the equinoxes. The visual effect is that of seeing the Sun rise in the west." http://en.wikipedia.org/wiki/Terminator_(solar) http://en.wikipedia.org/wiki/Terminator_(solar)
- jeroen94704 14y agoCool! So you could find a spot somewhere up north where you can take a stroll and experience an eternal sunrise/sunset. Very romantic :)
- ColinWright 14y ago747-400, but a long way north.
- dfranke 14y agoYou didn't mention any assumptions that get screwed up by the presence of leap seconds. N. There are 60 seconds in every minute. N+1. UNIX timestamps always advance monotonically.
- Shenglong 14y agoAlso don't forget that different time zones convert to DST at different offsets, and some places don't observe DST altogether. Oh, and some places go backwards.
- lacker 14y agoNot just "some places" go backwards. UTC itself can jump backwards during a leap second. http://en.wikipedia.org/wiki/Leap_second http://en.wikipedia.org/wiki/Leap_second
- arohner 14y agoN+?? The time library in your programming language is correct. Every time library I've ever dealt with will have serious problems with at least one issue listed on the original article or in the comments here. JodaTime (on the JVM) is by far the best, but even they have problems, and are creating a new library to solve those.
- henrikschroder 14y ago> and are creating a new library to solve those. Now they have N+1 problems.
- MarkMc 14y agoI think that for the vast majority of real-world software applications JodaTime is bloated and unnecessary. Most applications need only three 'classes' to represent time: 1. A timestamp (ie. number of milliseconds since midnight on 1 January 1970 GMT) 2. A Gregorian Date (ie. three numbers representing day, month, year) 3. A TimeZone (to convert between 1 and 2) In Java the first and third types are perfectly represented by java.util.Date and java.util.TimeZone. The second class can be represented by something like this: http://calendardate.sourceforge.net/ http://calendardate.sourceforge.net/ (Disclaimer: I wrote CalendarDate)
- rmc 14y ago1. A timestamp (ie. number of milliseconds since midnight on 1 January 1970 GMT) You know that's not unix time, right? Unix time doesn't include leap seconds.
- endlessvoid94 14y agoIf you haven't read "Great unsolved problems in computer science", I'd highly recommend it: http://algeri-wong.com/yishan/great-unsolved-problems-in-computer-science.html http://algeri-wong.com/yishan/great-unsolved-problems-in-com... TL;DR: calendaring is hard. really hard.
- Florin_Andrei 14y ago> 32. A time stamp of sufficient precision can safely be considered unique. I'm so guilty of that one.
- ams6110 14y agoThis sort of stuff is why I scream "NNNNOOOOOOOOOOOOOO!!!!!!" when people store date/time as integers (i.e. "unix timestamps") when almost every database and programming language has a proper date or datetime data type, and a boatload of library functions that correctly compute differences between dates, handle leap years and time zones, etc. Well maybe not always correctly, but it's more likely that YOU will screw up your date math than it is that the well-tested date library will.
- rdwallis 14y agoAt least in Java, storing a date/time as a primitive improves immutability and is a good pattern. You don't expose the underlying long value publicly so you end up with something like the following: private long primitiveDate; public Date getDate() { return new Date(primitiveDate); } ----- This prevents calling methods from doing something stupid like: o.getDate().setTime(123455L) to modify a date that shouldn't be editable.
- taftster 14y agoOr possibly better: private Date date; public Date getDate() { return new Date(date.getTime()); }
- rdwallis 14y agoYour code solves the external side effects problem but using the primitive also allows the time to be finalized eg: private final long creationTime = System.currentTimeMillis(); so it still has advantages over making the field a Date object.
- rlpb 14y ago> when almost every database and programming language has a proper date or datetime data type, and a boatload of library functions that correctly compute differences between dates, handle leap years and time zones, etc. In Unix-land, this data type and boatload of library functions is the operating system. The system provides and deals with local time conversion when necessary. If your application isn't very involved with time (eg. it's not a calendar or scheduling application) then it is sensible to use Unix timestamps. This ties you to a Unix OS, which isn't usually too bad a decision since other more important things do as well. On the other hand, using your programming language or database ties you to that database or language, which is arguably worse.
- jhawk28 14y agoHe missed the myth that "Time always moves forward"
- adobriyan 14y agoThe myth is "Time always moves equally forward everywhere".
- mck- 14y agoThere needs to be an Internet Standard Time/Date -- at least in terms of formatting.
- estel 14y agoWhat about ISO 8601? http://en.wikipedia.org/wiki/ISO_8601 http://en.wikipedia.org/wiki/ISO_8601
- jhawk28 14y agoAnother way to look at time is this: The only correct clock is a broken one which is right twice a day.
- user49598 14y agoYou forgot about daylight savings. If the day is one on which we either spring forward or fall back and the time the clock reads somewhere in the shift hour, then the clock will be right either 1 or 3 times that day. And it's different in different countries. https://en.wikipedia.org/wiki/Daylight_saving_time#Procedure https://en.wikipedia.org/wiki/Daylight_saving_time#Procedure
- jmpeax 14y ago"The smallest unit of time is a milli/second" seems a bit silly, as it really depends on your application. Is he expecting programmers to implement time in Planck units?
- srparish 14y agoIt's not uncommon for languages and libraries to assume that millis are the smallest resolution. Java is getting better, but is still pretty hit or miss. But if you're writing performance sensitive code you're definitely in micros and maybe in high nanos. There's a lot of those in a millisecond.
- NoahSussman 14y agoThe specific issue that bit me wrt units of time was seconds vs. milliseconds. This came up the first time I needed to mix PHP time stamps with Jenkins build log time stamps. One is in seconds, the other in milliseconds. Unfortunately the PHP date() function exhibits odd behavior when a time stamp contains two extra digits. I could have saved myself the debugging time had I not been so attached to the assumption that time stamps are always in seconds rather than sometimes in milliseconds.
- pjscott 14y agoThis is why I really like logical clocks: by abandoning the primitive and outdated concept of "time" altogether, they allow you to deal reliably with causality, which is often all you're really interested in. http://en.wikipedia.org/wiki/Lamport_timestamps http://en.wikipedia.org/wiki/Lamport_timestamps http://en.wikipedia.org/wiki/Vector_clocks http://en.wikipedia.org/wiki/Vector_clocks That said, UTC timestamps since the epoch are one of the more straightforward ways of dealing with time, if you must sully your hands with the foul concept of time at all.
- maw 14y ago> That said, UTC timestamps since the epoch are one of the more straightforward ways of dealing with time, if you must sully your hands with the foul concept of time at all. Definitely. Leave their rendering to the experts, but to store times and dates in any other way is indefensible.
- rmc 14y agoUTC timestamps since the epoch Since we add leapseconds, and UTC includes those leap seconds, it's hard to know "time since the epoch". For example, unix/posix time is not the number of seconds since the epoch.
- bluesmoon 14y agoSpeaking of timestamps being in recognizable formats, here's a list of interesting timestamps I've seen on (mostly) iOS devices: http://stackoverflow.com/questions/11023086/how-do-i-interpret-these-strange-javascript-timestamps-from-mobile-phones http://stackoverflow.com/questions/11023086/how-do-i-interpr... If anyone has any idea about what they could possibly mean, I'd much appreciate it.
- stox 14y agoMissed the most important one for this month, minutes always have 60 seconds. Except for the end of this month, when one minute will have 61 seconds, ie, Leap Second.
- uvTwitch 14y ago"This will only take a few minutes."
- NoahSussman 14y agoHeh for this I like Cheops' Maxim: "nothing is ever built on time or within budget." There's also Hofstadter's Law: "it always takes longer than you expect, even when you take into account Hofstadter's law."
- technomancy 14y agoI can't believe this omits my personal favourite misconception: "Time always goes forwards."
- finnw 14y agoN. The local time offset (from UTC) will not change during office hours. I got bitten by this once when developing a scheduling tool for project management. Since daylight-saving offset changes were always close to midnight, I assumed they would not occur while anyone was using my program (and there was no point in using it outside "office hours.") Then a technician on a night shift used my program on the night DST kicked in, it went into an infinite loop and took down the CRM database server, disabling automatic software updates and an (unrelated) DRM system.
- finnw 14y agoN. The local time offset (from UTC) will not change during office hours. I got bitten by this once when developing a scheduling tool for project management. Since daylight-saving offset changes were always close to midnight, I assumed they would not occur while anyone was using my program (and there was no point in using it outside "office hours.") Then a technician on a night shift used my program on the night DST kicked in, it went into an infinite loop and took down the CRM database server, disabling automatic software updates and an (unrelated) DRM system.
- michaelochurch 14y agoThread.sleep(1000) sleeps for 1000 milliseconds.
- cpeterso 14y agoOr that Thread.sleep(1000) sleeps for >= 1000 milliseconds.
- TazeTSchnitzel 14y agoOr that Thread.sleep(x) is anywhere near x.
- derleth 14y agoA meta-misconception: It's possible to establish a total ordering on timestamps that is useful outside your system. Virtual machines can be screwed with comprehensively. So can non-virtual ones, come to that, and your software likely isn't in a position to tell that it's already seen 02:34:17 GMT 2013-05-25 five times already. So what can you do about that? Bloody nothing. Absolutely nothing whatsoever. You're screwed. Everything you could do can be screwed with in ways your program can't defend against. The lesson: Don't worry about bugs you can't fix. Refusing to play games you can't win will keep your hair in your head a lot better than knowing the intricacies of human timekeeping systems past and present.
- einhverfr 14y agoI 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 other hand, requiring that clocks be set to within, say, five minutes (Kerberos 5) is a design consideration. This is why Kerberos is usually used with something like NTP. But beyond this there are a lot of things you can't do (like expire cookies) if you don't assume that client and server have similar times on their clocks. Sometimes it makes sense to require things you can't assume to always be true.
- derleth 14y ago> 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 is void and the software can only fail. Either. Side. 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.
- adavies42 14y ago> 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
- NoahSussman 14y agoI could tell you some stories about not being able to expire cookies.
- darylteo 14y agoWasn't there a post about how 1 day this year will be 1 second longer? Can't remember it... leap second?
- acoster 14y agoYes - June the 30th has a leap second ( http://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat http://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat ).
- rickdangerous1 14y ago"7. 7.A week (or a month) always begins and ends in the same year." Not sure what the (or a month) is doing there. I'm pretty sure the end of december is the end of the year and the beginning of January is the beginning of the year. A month can't span multiple years...can it?
- NoahSussman 14y agoYou are right. I said "a month" but I meant something more like "a period of 28 days" or "a month-long period." I'll think about how to word this more clearly.
- rmc 14y agoYears start on Sept. 11th in Ethiopia http://en.wikipedia.org/wiki/Ethiopian_calendar http://en.wikipedia.org/wiki/Ethiopian_calendar
- damian2000 14y agoDST is an evil perpetrated by curtain and blind manufacturers so that their products need replacing more often due to UV damage. Oh yeah, its the cause of global warming as well.
- MichaelGG 14y ago> 1. There are always 24 hours in a day. Can someone explain when this isn't true? Is he referring to leap seconds, or local timezone DST changes? Or something more interesting I'm failing to think of?
- pestaa 14y agoEvery day is slightly longer than 24 hours, accumulating more than 6 extra hours every year (hence leap years.) Other than that, I can only think of local DST changes you mentioned.
- PeterisP 14y agoDST changes are a big issue. A simple example from real life - there is a system that takes a measurement every hour, 24/7. Make a report that prints a table of the historical measurements for each day. Does your report show correctly that some days have 24 rows, some have 25 rows and some 23?
- Osiris 14y agoI 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 Time" (used by Outlook) is the same as "US/Arizona" (used by PHP among others).
- BrandonM 14y ago> "US Mountain Standard Time" (used by Outlook) is the same as "US/Arizona" (used by PHP among others). It's not quite that simple. During Daylight Saving Time, Arizona stays on US Mountain Standard Time; i.e., it's the same as Pacific Daylight Time and one hour behind Mountain Daylight Time. During the rest of the year, Arizona is on the same time as the rest of Mountain Standard Time, or one hour ahead of Pacific Time.
- adavies42 14y agothe "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....
- cperciva 14y agoSome more falsehoods: 1. Time never goes backwards (as other people have pointed out, time zones break this). 2. UTC time never goes backwards (as other people have pointed out, leap seconds break this). 3. The system boot time never changes. On most platforms, the current time is defined as "boot time plus uptime", and setting the current time is performed by changing the boot time. 4. System uptime never goes backwards. Some platforms handle setting the current time by changing the system uptime. 5. POSIX's CLOCK_MONOTONIC never goes backwards. On some platforms and virtualization environments this can break with CPUs shared between virtual machines. 6. On systems without virtualization, CLOCK_MONOTONIC never goes backwards. On some platforms this can occur due to clock skew between CPUs.
- exDM69 14y ago> 5. POSIX's CLOCK_MONOTONIC never goes backwards. On some platforms and virtualization environments this can break with CPUs shared between virtual machines. > 6. On systems without virtualization, CLOCK_MONOTONIC never goes backwards. On some platforms this can occur due to clock skew between CPUs. Could you explain these situations in more detail? Or cite a source I can take a look at? CLOCK_MONOTONIC is what I use for timing quite often. I tend to do soft real time stuff and that clock seems the best suited for my tasks.
- __alexs 14y agoIf CLOCK_MONOTONIC goes backwards your platform's implementation is broken. As defined in POSIX it does not ever go backwards. It counts the time since an unspecified point in the past that never varies after system start-up. If your process is rescheduled to a different CPU, it must still go forwards regardless of TSC variance between the CPUs. Of course if your uptime hits 68 years or so, the clock will wrap. If your app can't have any downtime in 68 years though I hope you've got the budget to think about this sort of thing :)
- cperciva 14y ago(5) is just a specific instance of the general principle "virtualization screws everything up". The most common issue is with virtualization systems trying to hide the fact that time is being "stolen" by the hypervisor and/or other domains. (6) is a case of "synchronization is really hard" combined with "benchmarks measure system performance, not system correctness". Most high-performance timing these days involves reading an on-die clock counter, scaling, and adding a base (boot time) value. For that to work on SMP, the clocks need to be synchronized -- and they don't start that way, since CPU #0 is enabled first and does some hardware probing before it turns the other CPUs on. Even worse, on many platforms, power-saving features will slow down the clock, resulting in the counters getting out of sync. As alexs says, CLOCK_MONOTONIC should be monotonic... but in reality, it's much faster to return a mostly-good-enough value. In FreeBSD, in addition to CLOCK_{UPTIME, REALTIME, MONOTONIC}, we have CLOCK__{FAST, PRECISE} so that applications can choose between accuracy and performance. CLOCK_MONOTONIC is what I use for timing quite often. I tend to do soft real time stuff and that clock seems the best suited for my tasks.* As long as you avoid virtualization, turn off all power-saving features, and your "soft real time" can tolerate non-monotonicity on the sub-microsecond scale, you should be safe.
- nsns 14y agoYou can sum most of it up with: the belief that calendrical (human-conventional) time is identical to, or acts the same as, or is inherently related to, physical time.
- JoshTriplett 14y agoI'd question #34 on this list somewhat: while formats like mm/dd/yyyy and dd/mm/yyyy definitely allow ambiguous interpretations, the ISO format yyyy-mm-dd seems fairly unambiguous; I've never seen any instance of yyyy-dd-mm floating around to confuse it with.
- mooism2 14y agoIt's ambiguous for human users who are not familiar with the format. Some people may not even recognise it as a date, in some contexts. (2012-06-19, that's 1,987 right?)
- TazeTSchnitzel 14y agoMake it clear, then. Put "Date:" next to it, and y m d above it in small type.
- cpeterso 14y agoIn Vernor Vinge's A Deepness in the Sky, the Unix epoch is still used thousands of years in the future, but "programmer archaeologists" of the time mistakenly believe that was the date when humans first landed on the moon. They also measure time in kiloseconds and megaseconds because "day" or "week" don't mean much for interstellar travelers. https://en.wikipedia.org/wiki/A_Deepness_in_the_Sky#Interstellar_culture https://en.wikipedia.org/wiki/A_Deepness_in_the_Sky#Interste...
- pm24601 14y agoMy 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 http://www.railway.co.th/home/Default.asp?lenguage=Eng (look on the right side: "booking can be until : 18/8/2555"
- TazeTSchnitzel 14y agoIn North Korea it's 100 IIRC
- rmc 14y agoIn Ethiopia it's about 2004 http://en.wikipedia.org/wiki/Ethiopian_calendar http://en.wikipedia.org/wiki/Ethiopian_calendar
- jasey 14y agoI took over from Snr dev who made 2 simple and bad time mistakes. 1) implementing their own DateAdd functionality in c# and forgetting about leap years. 2) thinking the app server and db server's time would never get out of sync. Fml he was so bad I wanted to kill him almost every day and got paid quite a bit more than me
- edanm 14y agoHow 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 most calendars write as "Wednesday" will actually start on Tuesday night, and last until Wednesday night.
- Mvandenbergh 14y agoOr anyone living in the Arab Middle East where: 1. Weeks start on a Sunday 2. Friday and Saturday are the weekend, except where it's Thursday and Friday 3. Some countries have changed their weekends in the last 10 years to Fri/Sat to make doing business internationally easier 4. Not everyone has a two-day weekend 5. Religious holidays depend on moon sightings and cannot be precisely predicted ahead of time
- adavies42 14y ago> 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?
- edanm 14y agoWell technically it's when 3 stars come out. Actually I just checked to make sure, it turns out the 3 stars thing is based on a definition by Maimonides: http://en.wikipedia.org/wiki/Jewish_calendar#Measurement_of_hours http://en.wikipedia.org/wiki/Jewish_calendar#Measurement_of_....
- georgew3 14y agoActually, in Jewish tradition, children are taught that the day begins at sunset. The justification comes from Genesis... "And God called the light Day, and the darkness he called Night. And the evening and the morning were the first day." The Moon is not mentioned.
- jheriko 14y agoYes, 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.
- TazeTSchnitzel 14y agoSo what does make use then?
- TazeTSchnitzel 14y agoSo what does make use then?
- gwalker 14y agoI've always thought that the GNU date command captured this confusion well. On Linux, if you run `info date` and go to "input date formats": Our units of temporal measurement, from seconds on up to months, are so complicated, asymmetrical and disjunctive so as to make coherent mental reckoning in time all but impossible. Indeed, had some tyrannical god contrived to enslave our minds to time, to make it all but impossible for us to escape subjection to sodden routines and unpleasant surprises, he could hardly have done better than handing down our present system. It is like a set of trapezoidal building blocks, with no vertical or horizontal surfaces, like a language in which the simplest thought demands ornate constructions, useless particles and lengthy circumlocutions. Unlike the more successful patterns of language and science, which enable us to face experience boldly or at least level-headedly, our system of temporal calculation silently and persistently encourages our terror of time. ... It is as though architects had to measure length in feet, width in meters and height in ells; as though basic instruction manuals demanded a knowledge of five different languages. It is no wonder then that we often look into our own immediate past or future, last Tuesday or a week from Sunday, with feelings of helpless confusion. ... -- Robert Grudin, `Time and the Art of Living'.
- MicahWedemeyer 14y agoWhile these are all valid issues, and good to be aware of, don't rush out and fix all your "broken" code. Plus, don't climb up on a pedestal and lecture your fellow developers on their "falsehoods" about time. Use your experience to know when exactness is important and when it's not.
- Morg 14y agoReally - wtf. that list is so full of .. something 1-7 : try going to school. 8-18 : if server time is not absolute, shoot yourself in the face, client time should never matter 19 : doesn't matter 20 : epoch64bit will be there everywhere before 2020, if you run unupdated 20 year old OS's you deserve bugs anyway. 21-25 : Expect bugs in every new shiny toy, like virt 26-27 : The smallest unit of time is one clock cycle, the rest doesn't exist 27-28 : see 8-18 29 : timestamps should never be anything else than integers, the only acceptable formats are 32/64bit epoch (+ 32/64bit subsecond), and handling data without knowing what it is ... is dumb, so of course it fails 30-31 : If you like mixing data, I can give you a binary string to mix with your 32bit epochs 32 : A timestamp with sufficient precision (1cycle) based on UTC taken after a sync with a time server, is unique per processor / core / thread - any non-uniqueness of a timestamp is directly related to an implementation mistake - it is indeed possible to have perfectly unique timestamps (not 32bit epoch of course) 33 : whatever 34 : noone cares about human stuff. Note: Unsurprisingly the author is a webdev and not a programmer.
- kvz 14y agoI assumed a year had 52 weeks. 2009 had 53.
- adavies42 14y ago* highly-precise (nano-second or better) time has any intrinsic meaning at all (relativity)
- adavies42 14y ago* floats are ever a good idea for storing time. a system i use (no, not excel) has one of its time types defined as a double of days since their epoch. the problem is that it's universally represented in the interface as a timestamp to millisecond precision, and many different values may have the same string representation. i just ran a quick test, and for a specific millisecond around now, about 13,000 distinct timestamps have the same string representation. if you use that string representation as a serialization of any one of those timestamps, it will always map back to a single float value, which will be only one of those 13,000, meaning the others aren't round-trippable. the system implements a comparison tolerance for floating point numbers, but this helps only slightly, as only about 1100 of those 13,000 test as equal to the one you get if you enter it as a string. the end result is that you can have data printing to the screen that you can't actually find in the system because its string representation doesn't match its internal one due to precision issues. (the solution is not to use the type--they deprecated it in favor of one based on longs of nanos several years ago.)
- charlieok 14y agoFrom the headline, my first thought was that this was going to be about estimating development time/effort on a project.
- NoahSussman 14y agoFalsehoods we believe about estimating development time/effort: 1. For any non-trivial project, it is possible to estimate development time and/or effort with a reasonable degree of accuracy.
- adavies42 14y ago* durations and points are commensurate points in time are relative to some fixed point, and are (more or less) dimensionless. durations are not, and are (more or less) vectors. this has a couple consequences: durations are independent of epoch, while points aren't, and only certain types of math make sense with each. basically, the only thing you can do with two points is subtract them (yielding a duration)--the rest of arithmetic (including addition) is meaningless. the only things you can do with a point and a duration is add or subtract them (yielding a point). you can't do anything at all with a point and a dimensionless scalar. the only things you can do with two durations is add or subtract them (yielding a duration) or divide them (yielding a scalar). the only things you can do with a duration and a scalar is multiply or divide them. (personally i'd say that even the commutative operations shouldn't necessarily be commutative--i'd say point+duration->point, but duration+point->undefined--but that may be a bit too strict.) as a quick rule of thumb, if your code would break if you changed epochs, it's already broken.
- kizza 14y ago"Time zones are an integer number of hours away from UTC" As someone living in +0930, programmers get this wrong way too often - Crittercism gets this wrong, so I don't know when bugs happened in my apps.