5 ms·
You can pry my "<milli|micro>seconds since the epoch" timestamps from my cold dead hands.
by metabrew 14y ago
You can pry my "<milli|micro>seconds since the epoch" timestamps from my cold dead hands.
- roel_v 14y agoSo you software doesn't support timezones? Good luck with that.
- TazeTSchnitzel 14y agoYes it does. Store UTC times, display in local timezone.
- mitchty 14y agoI 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.
- ZenPsycho 14y agowhich, 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.
- mitchty 14y agoMad 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!
- lloeki 14y agoYou'll shoot yourself soon enough when you will need to handle timezones and become sick of inventing your own ∆epoch+TZ format :-)
- jewel 14y agoUnix timestamps are amount of time since the epoch in GMT, so there is no need to store the timezone.
- TazeTSchnitzel 14y agoYou mean UTC? GMT is tied to London, and could be confused with BST during summertime. UTC isn't.
- rmc 14y agoYes. 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.
- lloeki 14y agoAttaching 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.
- DrJokepu 14y agoA 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.
- TazeTSchnitzel 14y agoI like to have a floating point value of seconds since the epoch for my dates. Python is a wonderful language.
- zdw 14y agoThen you'll just love TAI64: http://cr.yp.to/libtai/tai64.html http://cr.yp.to/libtai/tai64.html