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

61–70 of 74 posts

Re: Timestamps done right

#61

Post by jandrese »

henrikschroder wrote: post #59
jandrese wrote: post #56

Earlier quoted context omitted.

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…

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.

Re: Timestamps done right

#62

Post by nickpsecurity »

ehartsuyker wrote: post #55
nickpsecurity wrote: post #30

Earlier quoted context omitted.

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

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.

Re: Timestamps done right

#63

Post by nickpsecurity »

32bitkid wrote: post #39
nickpsecurity wrote: post #37

Earlier quoted context omitted.

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.

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.

Re: Timestamps done right

#64

Post by nickpsecurity »

henrikschroder wrote: post #46
TimWolla wrote: post #38

Earlier quoted context omitted.

February 2012 has got 29 days.

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

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.

Re: Timestamps done right

#65

Post by jandrese »

zimbatm wrote: post #60
jandrese wrote: post #56

Earlier quoted context omitted.

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.

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.

Re: Timestamps done right

#66

Post by nickpsecurity »

henrikschroder wrote: post #45
xixi77 wrote: post #43

Earlier quoted context omitted.

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.

By splitting the addition up into two discrete calls, the ordering is made much more explicit, there's no room for ambiguity. In C#, the largest part of a TimeSpan is a day, you can't have a TimeSpan of "one month and one day", because adding that to a DateTime would add a different amount of absolute time depending on the DateTime. You can have a TimeSpan of "32 days", and adding that to any DateTime yields a consis…

1h4m is 1 hr then 4 min. Order is explicit unless language rules obfuscate it.

Re: Timestamps done right

#67

Post by nickpsecurity »

ehartsuyker wrote: post #54
nickpsecurity wrote: post #29

Earlier quoted context omitted.

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.

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.

Re: Timestamps done right

#68

Post by BraveNewCurency »

jandrese wrote: post #65
zimbatm wrote: post #60

Earlier quoted context omitted.

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.

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.

> SECONDS_PER_DAY is constant for human scale activities.

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

Re: Timestamps done right

#70

Post by unabashedturtle »

I work with timestamps A LOT. In fact, I often have to deal with streams of 5 million + /second. Even worse, for most of them, microsecond precision is critical.

I'm convinced most languages do timestamps wrong. Specifically, they separate out the "time" component from the "date" component.

What's a more common operation? Counting how many events happened in a span of time? Or shifting every timestamp by 15 days?

Timestamps should generally be designed for extremely fast and lightweight comparison, but keep enough information that a shift is doable. From my experience, all you need is: a unix timestamp, a microsecond (or nanosecond) offset, and the source timezone.

In this case, if you want to find elapsed time between two timestamps you simply subtract the unix timestamps and offsets. Very CPU friendly and easily vectorizable. You can do this even if the timestamps originated at different timezones (since everything is UTC under the hood).

What if you want to shift the date? Or group by date? Turns out computing the date on the fly is a very cheap operation. Easily can do hundreds of millions/second on a single high-end server core.

an use whatever calendar system floats your boat.

Any timestamp system that relies on year/month/day semantics is rarely going to be optimized for the most common operations users do with timestamps. Even worse, for simple comparison you run into all the weird edge-cases that you wouldn't have cared about if you stuck with a unix timestamp under the hood.

Post reply on HN