You'll shoot yourself soon enough when you will need to handle timezones and become sick of inventing your own ∆epoch+TZ format :-)

Unix timestamps are amount of time since the epoch in GMT, so there is no need to store the timezone.

Nope. They don't include leap seconds.

The technical definition is "Number of days since 1st Jan 1970 in GMT" × 86400 + "Number of seconds since midnight GMT"

Unix time clocks does funny things when there's a leap second which is about 1½ years. Some pause for a second, some go forward then backward etc.

Attaching a timezone to a time is an information in itself. By coercing time data to UTC you are losing this bit of information.

A user may want to have some information shown as 8AM PST at the same time he wants another one shown as 8AM CET.

A timestamp and a timestamp with time zone are two different things and you need to use the appropriate one (which is usually time zone with timestamp). However, the argument is really not about attaching timezone information to timestamp which is an unfortunate but necessary thing, but storing times in the archaic multiple-base mixed format stuff humans traditionally use (because it's human-friendly) that computers simply do not need. An ISO timestamp mixes bases 60, 24, 12, a weird mix of base 28, 29, 30 an 31, and a weird mix of 365 & 366. This is craziness.

You mean UTC? GMT is tied to London, and could be confused with BST during summertime. UTC isn't.

Yes.

Technically UTC = GMT and always has and for this "epoch time" conversation is completely identical.

However there's a people problem. Some people think "GMT = the time in London now" which it isn't, since the UK switches to BST for daylights saving. Saying "UTC" avoids the "time in London" interpretation problem.

Then you'll just love TAI64:

http://cr.yp.to/libtai/tai64.html

So you software doesn't support timezones? Good luck with that.

Yes it does. Store UTC times, display in local timezone.

I suppose the only drawback to using epoch alone would be if you need to remember the timezone the date was stored from. But thats easy enough to fix.

which, if you think the problem through enough you'll have to conclude that you do need to store the time zone, unless you just don't really care about having accurate times. Read through some of the other comments and you'll realize that there's certain kinds of calculations and comparisons you just can't do without the time zone, and a historical time zone database, and a leap seconds database. Do not make the mistake of assuming that dealing with times and dates can be easy.

Mad late reply but i use epoch when my time needs don't matter. Aka: I can get by without worrying about epoch not being second precise and I don't need to worry about dates except to display them in non UTC.

For my needs 90% of the time iso8601 is overkill and unnecessary.

But dates in what I do don't need to be complicated. Which is rare. Also I never said working with times and dates is easy, evaluate your needs for the situation. Going full tilt with timezones and full date parsing for some general server logs for example doesn't always make sense is all I'm saying. Tschuss!

I like to have a floating point value of seconds since the epoch for my dates. Python is a wonderful language.