Live data from Hacker News

Falsehoods Programmers believe about Time

infiniteundo.com

181–190 of 222 posts

Re: Falsehoods Programmers believe about Time

#183
post #166
post #129

Earlier quoted context omitted.

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

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

Hmm...I did not know that! I should really have said 'eg.' instead of 'ie.'

The point of the above 'timestamp' is is to represent a specific instant in time, independent of any time zone or calendar system. You can use Unix time for this purpose.

Re: Falsehoods Programmers believe about Time

#184
post #183
post #166

Earlier quoted context omitted.

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

Hmm...I did not know that! I should really have said 'eg.' instead of 'ie.' The point of the above 'timestamp' is is to represent a specific instant in time, independent of any time zone or calendar system. You can use Unix time for this purpose.

Depends. unixtime is for seconds, if you want to record 2 things that happen ¼ second apart, they might have the same value.

Also during leapseconds, unix time does funny things, like 2 second long 'seconds'. or it goes backwards to reset etc.

Re: Falsehoods Programmers believe about Time

#185
I'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'.

Re: Falsehoods Programmers believe about Time

#186
While 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.

Re: Falsehoods Programmers believe about Time

#187

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

It'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?)

Make it clear, then. Put "Date:" next to it, and y m d above it in small type.

Re: Falsehoods Programmers believe about Time

#190
Really - 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.

Post reply on HN