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

31–40 of 74 posts

Re: Timestamps done right

#31

Post by nickpsecurity »

32bitkid wrote: post #24
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)

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.

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

Re: Timestamps done right

#32

Post by nickpsecurity »

acveilleux wrote: post #23
de_Selby wrote: post #22

I'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...

It's definitely an improvement in reader comprehension. I'll admit one of the reason I didn't learn those languages is that they looked like gibberish.

Re: Timestamps done right

#34

Post by stygiansonic »

alblue wrote: post #11
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 :)

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.

Re: Timestamps done right

#35

Post by henrikschroder »

nickpsecurity wrote: post #31
32bitkid wrote: post #24

Earlier quoted context omitted.

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.

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

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

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

(edit: stupid leap-year!)

Re: Timestamps done right

#36

Post by bazzargh »

NyxWulf wrote: post #8
zimpenfish wrote: post #5

Earlier quoted context omitted.

You still need to record the timezone somewhere and you might as well just stick to ISO8601/RFC3339 format then.

One approach is to store numeric timestamps in UTC format. Then if you do have data stored in a different timezone you have to include the timezone with it. That is the default mode of operation for many of the standard date formats. If you get timestamp data from a system outside of your control though you always have to make sure you know what it means. At least half the time it seems like a date without a timezone…

That approach has limits, when DST raises its ugly head (for example, in a calendar scheduler). It's interesting that some of these systems ask you for timezones like "GMT London" - it appears to the user that they're asking for the three letter timezone, 'GMT' - which the user probably knows - but what they're really asking is the TZDB timezone location - which the user probably doesn't.

Re: Timestamps done right

#37

Post by nickpsecurity »

henrikschroder wrote: post #35
nickpsecurity wrote: post #31

Earlier quoted context omitted.

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

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.

Re: Timestamps done right

#38

Post by TimWolla »

henrikschroder wrote: post #35
nickpsecurity wrote: post #31

Earlier quoted context omitted.

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

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

February 2012 has got 29 days.

Re: Timestamps done right

#39

Post by 32bitkid »

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.

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.

Re: Timestamps done right

#40

Post by crispyambulance »

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

Post reply on HN