What every programmer should know about time

Post by barrkel » Mon, Jul 04, 2011, 4:13 AM UTC

wvenable wrote: post #29

geuis wrote: post #2

"Timezones are a presentation-layer problem! Most of your code shouldn't be dealing with timezones or local time, it should be passing Unix time around." I can attest to this. At a previous job our entire API used UTC. It was clean and worked at every layer of the app, from django to our client-side javascript. When we needed to display a human readable version, we did the translation at render time. All interactions…

Storing all your time as UTC can create problems depending on what you're doing with the time. If your application is a calendaring application and people can book things well into the future, you can have problems with daylight saving time and timezones this way. For my most recent app, timestamps are UTC and everything else is stored local time.

Post by jodrellblank » Mon, Jul 04, 2011, 4:17 AM UTC

jen_h wrote: post #26

"The system clock can, and will, jump backwards and forwards in time due to things outside of your control. Your program should be designed to survive this." This is one of my favorite go-to test cases. I've found some really fantastically interesting, catastrophic network halting badness with this really simple test.

Post by caf » Mon, Jul 04, 2011, 4:53 AM UTC

stoney wrote: post #32

matwood wrote: post #21

Earlier quoted context omitted.

You have to tell it a time zone or else the calendar app will not know what time you mean (and really, time without a time zone is meaningless). What you are doing is using your current time zone as the default so when you enter appointments from another time zone you're actually entering them incorrectly. Any calendar app should allow the entry of appointments with time zone.

> You have to tell it a time zone or else the calendar app will not know what time you mean It seems logical to me that whatever time I write in my calendar app is the time that I expect something to happen. I.e. it is the local time at wherever I happen to be. If I put in a meeting at 4pm on 8/7/2011, then I expect an alarm to sound whenever the local time is 4pm on 8/7/2011. That's how my paper diary works (or used…

Post by caf » Mon, Jul 04, 2011, 5:01 AM UTC

yoyar wrote: post #22

sgerrand wrote: post #3

As per gakman's comment in the Google+ crosspost[1], be wary of the Unix millenium bug[2] if you use integers for timestamp storage. [1] https://plus.google.com/106356964679457436995/posts/Hzq2P7V6... [2] http://en.wikipedia.org/wiki/Year_2038_problem

I wonder about storing the timestamp in a varchar field of sufficient size to avoid all of these headaches? Although I guess 64 bit will suffice for a very long time.

Post by chrisbolt » Mon, Jul 04, 2011, 5:07 AM UTC

stoney wrote: post #32

matwood wrote: post #21

Earlier quoted context omitted.

You have to tell it a time zone or else the calendar app will not know what time you mean (and really, time without a time zone is meaningless). What you are doing is using your current time zone as the default so when you enter appointments from another time zone you're actually entering them incorrectly. Any calendar app should allow the entry of appointments with time zone.

> You have to tell it a time zone or else the calendar app will not know what time you mean It seems logical to me that whatever time I write in my calendar app is the time that I expect something to happen. I.e. it is the local time at wherever I happen to be. If I put in a meeting at 4pm on 8/7/2011, then I expect an alarm to sound whenever the local time is 4pm on 8/7/2011. That's how my paper diary works (or used…