Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Falsehoods Programmers believe about Time

infiniteundo.com

Post reply on HN
Print view View original

111–120 of 222 posts

Re: Falsehoods Programmers believe about Time

#111

Post by apaprocki »

rlpb wrote: post #102
ams6110 wrote: 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…

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

> In Unix-land, this data type and boatload of library functions is the operating system.

Which can lead to problems as well. Basically when dealing with "local" time (DST), you need a reliable source of data and the question boils down to whether you want system administrators to keep OSes patched and up-to-date every time tzdata is updated, or whether that should be handled at the application layer.

Java chooses to bake in tzdata, and so do a number of other app-layer platforms. JS in the browser relies on the OS instead of bundling binary tzdata. Windows and a few commercial *nix platforms do not bundle tzdata either and maintain their own definitions. The crowd-sourced tzdata has demonstrated itself better than even what Microsoft ships in Windows. I don't know anyone who would claim a dataset other than tzdata is "better".

There might come a point in time where browsers have sufficiently advanced automatic patching invisible to the end user that they would be better off bundling tzdata internally rather than relying on the OS because they can guarantee their data is better in a higher percentage of cases. It all comes down to whose update system is more seamless and more likely to occur given all the external factors that come into play. (e.g., a user might have local machine privileges to apply browser updates, but not OS updates)

Re: Falsehoods Programmers believe about Time

#112

Post by vidarh »

apaprocki wrote: post #110
brazzy wrote: post #31

And 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 o…

Also, computer systems have different Gregorian calendars. Your system could use the proper Gregorian calendar and a system you're communicating with could be using the proleptic Gregorian calendar. Most people don't notice the difference because dates aren't frequently slung around < 1582 in the modern world, but if a system has an idea of an "unset" date being equal to 1/1/1 it could lead to an error if transmitted…

Not to mention dealing with the numerous differences in when the Gregorian calendar was adopted, which is great fun if you need to deal with dates even back to the early 1900's across borders.

E.g. the "October revolution" falls in November - Russia didn't change until the Bolcheviks took power in 1917. And Greece didn't switch until 1923... China switched in 1912, but different factions in the civil war used different systems and it wasn't until 1929 they got a single (Gregorian) calendar again.. And there are many other countries that switched "recently".

Re: Falsehoods Programmers believe about Time

#113

Post by taftster »

rdwallis wrote: post #91
ams6110 wrote: 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 e…

Or possibly better:

private Date date;

public Date getDate() { return new Date(date.getTime()); }

Re: Falsehoods Programmers believe about Time

#115

Post by rdwallis »

taftster wrote: post #113
rdwallis wrote: post #91

Earlier quoted context omitted.

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 e…

Or possibly better: private Date date; public Date getDate() { return new Date(date.getTime()); }

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

Re: Falsehoods Programmers believe about Time

#116

Post by cbr »

hc5 wrote: post #71
lambda wrote: post #54

Earlier quoted context omitted.

> September 1752 had 19 days: 1, 2, 14, 15, ..., 29, 30. That's only in the British Empire. Other countries moved to the Gregorian Calendar at different times. It began being adopted on 15 October 1582 (the day after 4 October 1582) in some Roman Catholic countries (Spain, Portugal, Italy, Poland). Russia didn't switch until 1918. So, you could also have: N+8. There is only one calendar system in use at one time. And…

N+9.1: Non leap years will never contain a leap day. http://support.microsoft.com/kb/214326

But that's a bug in Excel. "Non leap years will never contain a leap day" is true.

Re: Falsehoods Programmers believe about Time

#117

Post by zanny »

tomjen3 wrote: post #12
cpeterso wrote: post #2

Also, time is unidirectional.

Well time would be unidirectional, right? The computer clock might not be.

Ooooh, 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)

Re: Falsehoods Programmers believe about Time

#118

Post by derleth »

einhverfr wrote: post #106

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

Re: Falsehoods Programmers believe about Time

#119

Post by rickdangerous1 »

"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?
Post reply on HN