[ehartsuyker]

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

[32bitkid]

Personally, I think there is a more subtle conceptual idea that it glosses over that makes the more explicit Java version more "clean".

> D + 1m1d != D + 1d1m

Mixing time units like days, months, years (where units are intransitive) is, in my opinion, a bad idea.

[nickpsecurity]

Should be able to type or sanity check them like anything else. What specific issue are you worried about?

[henrikschroder]

2011-02-28 + 1m1d = 2011-03-29

2011-02-28 + 1d1m = 2011-04-01

(edit: stupid leap-year!)

[TimWolla]

February 2012 has got 29 days.

[henrikschroder]

This is why everyone hates working with time and date functions. :-)

[nickpsecurity]

Oh it's been a pleasant trip down memory lane for me let me tell ya. Probably why I haven't done that sort of thing in a long time haha.

[nickpsecurity]

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.

[32bitkid]

because 1m = [28d,29d,30d,31d] depending on which month you are in. By adding 1d, pre or post, it can alter the definition of 1m.

[xixi77]

Sure (assuming that's how a "month" is defined in this context -- I haven't actually read the whole article, so I'm not sure); but why do you find the Java syntax less confusing? They look pretty equivalent, except for one is shorter than the other.

[nickpsecurity]

Ih ok. Sounds like we can keep first style just make order of operations clear and with rules to catch this. Second syntax woukd appear to require same checks. Again, equivalent intent and problems with more verbosity in 2.

[henrikschroder]

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

[jandrese]

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 formatted differently. Everything gets normalized to the internal representation before you do work on it.

[henrikschroder]

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?

[jandrese]

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

[henrikschroder]

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

[jandrese]

That's one reasonable interpretation, except that it causes problems where Jan 30 + 1m == Jan 31 + 1m and also Feb 28 - 1m != Jan 30 or 31.

Luckily most people can ignore leap seconds, just like pretty much every system time library. Because they don't happen on regular intervals it is impossible to code a fixed rule for dealing with leap seconds so very few things even attempt it.

Time is hard enough to deal with already and few human scale things care about 1 second differences that happen once every 3-5 years or so.

> what should Siri do if you tell it to "move today's 1 o'clock to the next month" ?

This is an interesting question, because there are at least two valid options. If it is the 31st of the month, then maybe you want it to happen on the first of next month. Something a human secretary might intuit. On the other hand, you might mean moving the appointment back a whole month, unless it's the 31st and then you mean to have it a day earlier on the next month...

Like I said, this kind of logic gets you in ambiguous edge case hell in a hurry. FWIW, I don't think Siri even attempts to deal with a request like that.

A better solution is probably to require the person to be a bit more explicit in their request "Siri, move my 1 o'clock to next Tuesday".

Besides, these kinds of interactions aren't impossible with epoch time, they just require more work. One can argue that it would be good to make this sort of thing a little tougher as it will encourage the programmer to think harder about what they are doing and reconsider if it is a good idea.

[zimbatm]

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.

[jandrese]

SECONDS_PER_DAY is constant for human scale activities. People who fret over leap seconds are either overly pedantic about time or are working at high enough precision that they aren't going to be making crude adjustments like "plus 1 month from now".

Besides, I can practically guarantee that the libraries discussed here don't deal with leap seconds. They're going to get it just as wrong.

[BraveNewCurency]

> SECONDS_PER_DAY is constant for human scale activities.

Except for Daylight savings time, which adds or subtracts a whole hour to the day.

[skywhopper]

By my count it's over 30 characters less "clean". The Java syntax obscures some meaning and requires a lot more boilerplate in favor of less magical (and thus complex) syntax.

I agree that this sort of first-class datetime-type representation may not be appropriate for every language, but myself, I find it refreshing and brilliant, and I'd love to see more languages support this sort of syntax instead of overloading strings or using complicated objects or APIs.

It's like comparing the power and ease of using regular expressions in Perl or Ruby versus in Java or Python. In Perl and Ruby, regexes are built-in to the syntax of the language itself. They're a truly first-class type, like strings and integers are in all four languages, and like lists and dicts/hashes/associative arrays are in Perl, Ruby, and Python.

I'd love to see datetime objects promoted to similar first-class native syntax support in this way in more languages. It won't be appropriate everywhere, but in the right language it'd be amazing.

[ehartsuyker]

The Java is clean because it's perfectly understandable. I don't have to think about "+ 1m" meaning month, minute, or milli-. Verbose, yes, but the meaning is 100% unambiguous which I think makes it a better API.

> overloading strings

I'm pretty sure writing "+ 1m" is more of an overloading of a string than ".plusMinutes(1)".

[stanmancan]

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 if you haven't read it in the past.

[nickpsecurity]

"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 that I knew what the author was doing before I read the explanation. I'd probably do "min," "sec," "hr," etc to aid intuition, though. Esp avoid confusion on months vs minutes for m.

Then, there's the other example. It appears to create an object. It then calls a method on that clearly adds one month. It also calls a method of that method, that object... idk that language so I don't really know the semantics of what it's doing... to add 1 day.

One is definitely more clear and intuitive than the other. It also has the rare property of being easier to type. Epic win over whatever the other thing is. Not to say the other one was bad: still pretty clear. Just not as much as a straight-forward expression.

[ehartsuyker]

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.

[nickpsecurity]

What clarity? That's what I mean. The first example starts with a date then adds values to it. Second does same thing. I use neither language nor do tjme series but still knew tge intent. So all you're getting is extra keystrokes with same clarity.

[xixi77]

Length itself does not; but there is an obvious benefit to a syntax that is both short and clear -- when reviewing the code, it takes much less time to figure out what's happening.

Take matrix algebra for example: what takes less time to process (e.g. when debugging code) --

`a = b'*c+d` or

`a = matrixAdd(matrixMult(matrixTranspose(b),c),d)`

or perhaps

`a = b.inverse().times(c).add(d)`? What if there are hundreds of operations like that?

Now, there _might_ be people for whom syntax (3) is the clearest -- for example, these could be people who know some programming, but are not familiar with matrix data or operations. However, their convenience, or that of your grandparents, doesn't really matter: if it's a one-off job for them, figuring it out would take a very small fraction of their time and is not worth optimizing for, and if it's not, extra time to learn the syntax would more than pay for itself when they have to regularly work with it. We don't use words to describe such expressions in print for exactly the same reason! :)

[JadeNB]

> By my count it's over 30 characters less "clean".

If character count were really the ultimate measure of cleanliness, then we'd all be programming pointlessly (https://en.wikipedia.org/wiki/Tacit_programming) and using single-character names for any variables that slipped through. (That's not to say that shorter is never better, but rather that, when it is better, its brevity is not the only reason.)

[crispyambulance]

The java "syntax" doesn't matter.

The IDE provides context-sensitive cues as one types so that you don't have the cognitive paper-cut from having to think for even a second if "1m" means "one minute" or "one month".

At a deeper level, chaining method calls to build-up an object is perfectly understandable way to modify something like a date.

[xixi77]

They are both about equally clear, but the former syntax will always take less time to process (unless perhaps you are a Java programmer who is familiar with the latter syntax but unfamiliar with the former, in which case it's not a valid comparison anyway). If it's an analysis-oriented package with most of the work done at a REPL, less time to type, too.

[nickpsecurity]

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.

[ehartsuyker]

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.

[nickpsecurity]

I said elsewhere id add a letter to distinguish months, minutes, etc. Otherwise, you missing larger picture: it's a time series analysis language with an expression adding a value to a date. So the value's letters are a datatype or unit of time. That simple.