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

11–20 of 74 posts

Re: Timestamps done right

#11

Post by alblue »

stygiansonic wrote: post #4

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

Re: Timestamps done right

#13

Post by skywhopper »

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)

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.

Re: Timestamps done right

#15

Post by JadeNB »

NyxWulf wrote: post #7
DiabloD3 wrote: post #3

Why are we not using unix timestamps (seconds since the epoch) for timestamps on everything that doesn't require sub-second precision?

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 + 1 year is defined to be 2017-01-21, and today + 2 years is defined to be 2018-01-21; and, if not, then one faces other problems with intuition.

Re: Timestamps done right

#16

Post by ehartsuyker »

skywhopper wrote: post #13
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)

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…

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

Re: Timestamps done right

#18

Post by JadeNB »

skywhopper wrote: post #13
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)

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…

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

Re: Timestamps done right

#19

Post by kabdib »

DiabloD3 wrote: post #3

Why are we not using unix timestamps (seconds since the epoch) for timestamps on everything that doesn't require sub-second precision?

We're getting into domains where sub-second precision is pretty important. Logs, for instance; on s aystem handling thousands of messages a second, storing log entries at a resolution of one second gets . . . irritating.

I like Windows NT's system of seconds-since-1600-or-so in increments of 100 nanoseconds. That system has served me well. 100ns isn't crazy to read directly and often from a hardware register (talk to a hardware engineer about latching a rapid counter sometime...), it covers a reasonable range for humans (handles everyone currently alive, for their whole lifetimes and most events they care about) and it fits pretty well with events that occur in multiprocessor systems (I'll be saying something different if I ever work on systems with terahertz clock rates, though).

Re: Timestamps done right

#20

Post by lostcolony »

This is interesting, and I can see that adding 1d10m is easier than adding 24 * 60 * 60000 + 10 * 60000 to a (millisecond) timestamp. Though I have to guess m is minute, not millisecond or month.

But...the display and storage of a timezone is a datetime, and it doesn't appear to have a timezone attached. Meaning I'd still rather just store/retrieve/work with millis since epoch, since that avoids any ambiguity about what timezone the timestamp takes place in. With just a datetime...I can ~assume~ it's GMT, but...is it? Millis since epoch are the same across all timezones, there is no ambiguity; datetimes vary, and I have to make assumptions, and make sure my library/driver/etc handles conversions correctly.

Post reply on HN