Live data from Hacker News

Falsehoods Programmers believe about Time

infiniteundo.com

91–100 of 222 posts

Re: Falsehoods Programmers believe about Time

#91
post #74

This 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 u…

At 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.

Re: Falsehoods Programmers believe about Time

#92
post #84

Earlier quoted context omitted.

Except it doesn't account for leap seconds.

Is that true? Isn't that the responsibility of the whatever component that translates the number of seconds since Jan 1 1970 into a calendar?

POSIX requires that the Unix timestamp value be incremented by exactly 86400 per day, regardless of how many seconds that day actually contained.

https://en.wikipedia.org/wiki/POSIX_time#Encoding_time_as_a_...

Re: Falsehoods Programmers believe about Time

#94
post #46

Earlier quoted context omitted.

39. 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.

I'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 p…

In the same vein I can bet I have seen at last 5 implementation of date diffing using string representation.

Re: Falsehoods Programmers believe about Time

#98

Also 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.

Not just "some places" go backwards. UTC itself can jump backwards during a leap second.

http://en.wikipedia.org/wiki/Leap_second

Re: Falsehoods Programmers believe about Time

#99
N. 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.

Re: Falsehoods Programmers believe about Time

#100
N. 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.

Post reply on HN