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

Timestamps done right

getkerf.wordpress.com

Post reply on HN
Print view View original

51–60 of 74 posts

Re: Timestamps done right

#51

Post by jandrese »

stygiansonic wrote: post #34
alblue wrote: post #11

Earlier quoted context omitted.

The original Java date and time API was probably one of the worst APIs ever invented, as I describe in my answer on StackOverflow: http://stackoverflow.com/a/1969651 However the new javax.time APIs (created by Stephen Colebourne) are excellent and probably one of the best designed APIs. It's funny what twenty years difference can make :)

Totally concur. But date/time is a hard thing to get right! However, getting it wrong the first time is different than getting wrong again, as you pointed out with the Calendar type. 0 == JANUARY, but most other things are indexed from 1... Third time's the charm, I guess :) Getting the input from Stephen Colebourne (of Joda-Time fame) was undoubtedly a key point in getting this done.

Numbering months from 0 is obnoxiously common in these time APIs. This is one of the few edge cases where IMHO we should index from 1, because people frequently just use the numeric version for output and it is way too easy to forget to add or subtract 1 from the month value. The memory lost by having an empty 0 spot in the month name array is absolutely not a concern in any sane project.

Re: Timestamps done right

#52

Post by henrikschroder »

jandrese wrote: post #47
ehartsuyker wrote: post #2

> I mean, just try it in Java. For ages JodaTime actually nailed it, and the Java 8 date API was based off this. > Not an add on type as in R or Python or Java. Again, let's talk about the modern version of the language and not act like prior screw ups are the end all for a language. Also > 2012.01.01 + 1m1d How is that more clean than: > new DateTime(2012, 1, 1).plusMonths(1).plusDays(1)

IMHO, working on timestamps in code like this is just asking for edge case to bite you in the ass. The only sane way I've found to work with time is to convert any timestamp into a seconds-since-the-epoch value when doing any internal work and then covert back to the timestamp format for display. As an added bonus your code won't get super messy when you start getting timestamps from different sources that are format…

You can't perform the operations "add one month" or "add one year" if you're working with seconds since the epoch.

For storing a timestamp, absolutely, you should use an integer-based format, counting discrete somethings since somewhen.

For working with timestamps, you need all the nuance, you need something that can manipulate the different parts of it independent of each other.

And finally, for displaying or reading timestamps, you need all the localization and parsing crap to figure out what "020304" means. Fourth of March 2002? Third of February 2004?

Re: Timestamps done right

#53

Post by henrikschroder »

nickpsecurity wrote: post #37
henrikschroder wrote: post #35

Earlier quoted context omitted.

2011-02-28 + 1m1d = 2011-03-29 2011-02-28 + 1d1m = 2011-04-01 (edit: stupid leap-year!)

Why does that happen? I'd think they were equivalent. I don't do time-series or anything to be clear. I would just expect the a + b = b + a principle to apply for the m/d value.

2011-02-28 + 1m1d = (2011-02-28 + 1m) + 1d = 2011-03-28 + 1d = 2011-03-29

2011-02-28 + 1d1m = (2011-02-28 + 1d) + 1m = 2011-03-01 + 1m = 2011-04-01

Also, you have these overflow rules:

2011-03-31 + 1m = 2011-04-30

2011-04-30 - 1m = 2011-03-30

Re: Timestamps done right

#54

Post by ehartsuyker »

nickpsecurity wrote: post #29
ehartsuyker wrote: post #2

> I mean, just try it in Java. For ages JodaTime actually nailed it, and the Java 8 date API was based off this. > Not an add on type as in R or Python or Java. Again, let's talk about the modern version of the language and not act like prior screw ups are the end all for a language. Also > 2012.01.01 + 1m1d How is that more clean than: > new DateTime(2012, 1, 1).plusMonths(1).plusDays(1)

Because one is an expression like humans think of it and one is a pile of OOP. The former is more desirable. The data types are also obvious.

How is "1m" more obvious that "plusMonths(1)"? I mean really, the latter is basically and English phrase. I know it's cool to shit all over OOP and Java these days, but if Haskell/Clojure/Whatever had a function (plusMonths dt 1) or something that, you wouldn't call it a pile of FP.

Re: Timestamps done right

#55

Post by ehartsuyker »

nickpsecurity wrote: post #30
stanmancan wrote: post #27

Earlier quoted context omitted.

How is plusMonths(1).plusDays(1) obscure in any way? You could show that to my grandparents and they would be able to guess what it does. "+1m1d" on the other hand they wouldn't have a clue. Length, in either direction, does not correlate to "clean". Clarity and intent does. Clean Coder ( http://www.amazon.ca/Clean-Code-Handbook-Software-Craftsmans... ) does a fantastic job talking about this, it's worth picking up i…

"Length, in either direction, does not correlate to "clean". Clarity and intent does." Exactly. So, the first example starts with a date in a way of representing dates that will register immediately for even a lay person. The developer intends to add time to that date. The example does this with an addition operator then a value with letters representing recognizable units of time. Matter of fact, this was so obvious…

In the former, typing '2012.01.01' implicitly creates a date object (probably), and '1m1d' implicitly creates some sort of duration object (probably) and uses an operator to combine them.

The Java was isn't really that different. Just more verbose, but again, I don't mind trading a few key strokes for clarity.

Re: Timestamps done right

#56

Post by jandrese »

henrikschroder wrote: post #52
jandrese wrote: post #47

Earlier quoted context omitted.

IMHO, working on timestamps in code like this is just asking for edge case to bite you in the ass. The only sane way I've found to work with time is to convert any timestamp into a seconds-since-the-epoch value when doing any internal work and then covert back to the timestamp format for display. As an added bonus your code won't get super messy when you start getting timestamps from different sources that are format…

You can't perform the operations "add one month" or "add one year" if you're working with seconds since the epoch. For storing a timestamp, absolutely, you should use an integer-based format, counting discrete somethings since somewhen. For working with timestamps, you need all the nuance, you need something that can manipulate the different parts of it independent of each other. And finally, for displaying or readin…

Yes you will need to have the localization logic when you convert the timestamps, but when you store them internally as timestamps you need that localization crap every single place you use them.

Adding 1 month or 1 year to the current date is usually a mistake. Quick question, what do you expect to happen when you code "Jan 31 + 1m"? What do you expect to happen when you code "Feb 29 2016 + 1y"? If you are thinking about doing this, ask yourself if it wouldn't make more sense to define your time by days instead. Jan 31 + 30 days, or Feb 29 + 365.25 days. Of course days are easy to implement on epoch time as well ( time + 30 * SECONDS_PER_DAY ).

Re: Timestamps done right

#57

Post by falsedan »

Doing timestamps right: use a library or class to abstract away the way the data is stored from the intent of the actions you want to perform on them.

What the article sez: GET KERF IT'S THE BEST AND ONLY WAY TO SOLVE THIS

Re: Timestamps done right

#58

Post by Jabbles »

philsnow wrote: post #49

When you build that syntax into the language / tokenizer, you're making a bunch of choices for the user. As many have said elsewhere in the thread, what is `m` supposed to mean, minute or month? If the smallest value you can represent with this special syntax is 1s, you're excluding people who work with sub-second timestamps. Unless, you want them to do like 1m0.0000415s or something like that, but now you have the s…

The ambiguity of "now + 1y" caused an outage for Azure:

https://azure.microsoft.com/en-us/blog/summary-of-windows-az...

Re: Timestamps done right

#59

Post by henrikschroder »

jandrese wrote: post #56
henrikschroder wrote: post #52

Earlier quoted context omitted.

You can't perform the operations "add one month" or "add one year" if you're working with seconds since the epoch. For storing a timestamp, absolutely, you should use an integer-based format, counting discrete somethings since somewhen. For working with timestamps, you need all the nuance, you need something that can manipulate the different parts of it independent of each other. And finally, for displaying or readin…

Yes you will need to have the localization logic when you convert the timestamps, but when you store them internally as timestamps you need that localization crap every single place you use them . Adding 1 month or 1 year to the current date is usually a mistake. Quick question, what do you expect to happen when you code "Jan 31 + 1m"? What do you expect to happen when you code "Feb 29 2016 + 1y"? If you are thinking…

> when you store them internally as timestamps you need that localization crap every single place you use them

Which is why you shouldn't do it, which is just what I said. :-)

> Adding 1 month or 1 year to the current date is usually a mistake.

No, I can think of many use-cases where this is useful. For example, what should Siri do if you tell it to "move today's 1 o'clock to the next month" ?

Jan 31 + 1m = Feb 28/29

Feb 29 + 1y = Feb 28

SECONDS_PER_DAY is not a constant, because of leap seconds. (Or it is, and shifting between UTC and UT1 causes them to appear. I forgot. It's messy no matter how you slice it.)

Re: Timestamps done right

#60

Post by zimbatm »

jandrese wrote: post #56
henrikschroder wrote: post #52

Earlier quoted context omitted.

You can't perform the operations "add one month" or "add one year" if you're working with seconds since the epoch. For storing a timestamp, absolutely, you should use an integer-based format, counting discrete somethings since somewhen. For working with timestamps, you need all the nuance, you need something that can manipulate the different parts of it independent of each other. And finally, for displaying or readin…

Yes you will need to have the localization logic when you convert the timestamps, but when you store them internally as timestamps you need that localization crap every single place you use them . Adding 1 month or 1 year to the current date is usually a mistake. Quick question, what do you expect to happen when you code "Jan 31 + 1m"? What do you expect to happen when you code "Feb 29 2016 + 1y"? If you are thinking…

I agree with the timestamp argument for storage but you might also want to keep the timezone/locale along.

Operation like "1 day from this timestamp" is locale-dependent. And SECONDS_PER_DAY is not a constant.

Post reply on HN