Regarding timestamps: https://howtologatimestamp.info/
Timestamps done right
21–30 of 74 posts
Re: Timestamps done right
#22I'm surprised the author is so big on kerf but doesn't mention q/kdb+[1] at all, which kerf took almost all these ideas from and which has a much bigger user base.
Re: Timestamps done right
#23I'm surprised the author is so big on kerf but doesn't mention q/kdb+[1] at all, which kerf took almost all these ideas from and which has a much bigger user base. 1) https://kx.com/
This should enlighten you why: https://scottlocklin.wordpress.com/2015/12/15/an-introductio...
Basically, he's big on Kerf because he's involved in the development. The above blog post will tie it with Kx and other APLs.
https://getkerf.wordpress.com/ is the official Kerf blog. And Kerf is not meant to be free...
Re: Timestamps done right
#24> 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)
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.
Re: Timestamps done right
#25This is just an aside, and not a knock on the article, but Java does have a built-in Timestamp type, [1] and has had it for some time. Maybe it's not "first-class" (not sure what this means in context?), but it's definitely there and not in a third-party JAR or anything. However, it's bad for other reasons, the first being that it extends java.util.Date (the Javadoc seems to admit this) and combined with the related…
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 :)
It's worth noting that much of the original java.util.Date class was based on the same misfeatures as POSIX C:
1. Leap seconds? Those don't exist, right? 2. Years date from 1900. 3. January is Month 0 (ignoring the fact that there is already a widespread convention of numbering January 1).
Of course, the "fix" of Calendar didn't attempt to fix any of the POSIX-did-it-first problems but instead mostly limited itself to supporting other locales by allowing non-Gregorian calendars.
Re: Timestamps done right
#26I wonder if a closed source language for data processing tasks can thrive on the long run. The concept for timestamps is nice though. But I do not want to spend time of learning proprietary languages.
Re: Timestamps done right
#27> 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)
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…
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.
Re: Timestamps done right
#28Earlier quoted context omitted.
They are difficult to read for humans. Without using a computer can you tell me when this timestamp was taken? 1453383978 Ultimately that was the point of the article, but the tone of the article about how they got it right and everyone else is wrong bugged me. My approach has been to store everything in epoch form, do all of my calculations and manipulations from there, then build tools that make converting back to…
Skimming the article doesn't make it clear whether they've addressed this, but, if you want to add units of time of non-constant size, then you cannot just use time-stamps. For example, `(today + 1 year) - today` is longer than `(today + 2 years) - (today + 1 year)` [0], so that one can't think of them as just `(today.unix + seconds_in_year).human` and `(today.unix + 2*seconds_in_year).human`. [0] Assuming that today…
Ugh. Every time I see time code, I'm thankful I work with monotonic subsecond times.
Re: Timestamps done right
#29> 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.
Re: Timestamps done right
#30Earlier quoted context omitted.
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…
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 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.