I'm looking at you Xcode...
I hit this problem once 10 years ago and learned the lesson ffs.
181–190 of 222 posts
I'm looking at you Xcode...
I hit this problem once 10 years ago and learned the lesson ffs.
He missed the myth that "Time always moves forward"
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.
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.
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.
Also during leapseconds, unix time does funny things, like 2 second long 'seconds'. or it goes backwards to reset etc.
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'.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?)
36. GMT and UTC are the same timezone.
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.