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