Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What every programmer should know about time

unix4lyfe.org

Post reply on HN
Print view View original

21–30 of 133 posts

Re: What every programmer should know about time

#21

Post by matwood »

cdcarter wrote: post #16
makmanalp wrote: post #13

Earlier quoted context omitted.

Well, this is also a presentation layer problem. You should be able to tell it to use your home zone instead of the current local zone, for example.

I don't want to tell it that though. I just want to enter things at a time, and have them stay at that time.

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.

Re: What every programmer should know about time

#22

Post by yoyar »

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.

Re: What every programmer should know about time

#23

Post by andrewcooke »

baddox wrote: post #17
cdcarter wrote: post #16

Earlier quoted context omitted.

I don't want to tell it that though. I just want to enter things at a time, and have them stay at that time.

Any calendar app either has to base its time zone on location or ask you to manually choose a zone. How would you propose changing this?

i think what is being suggested is something like storing it as a string and raising the alarm when the string matches the current local time. so it's "time in whatever time zone i am local to when it matches the time".

(which has problems with uniqueness, but does seem like an intuitive "dwim" high level interface).

Re: What every programmer should know about time

#24

Post by andrewcooke »

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

man 3p time suggests using time_t to "ease the eventual fix".

Re: What every programmer should know about time

#26

Post by jen_h »

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

Re: What every programmer should know about time

#27

Post by lysol »

I like to rip on MySQL as much as the next guy, but the article is incorrect about MySQL DATETIMEs:

DATETIME: Eight bytes: A four-byte integer packed as YYYY×10000 + MM×100 + DD A four-byte integer packed as HH×10000 + MM×100 + SS

Storing UNIX time as an integer would be silly, considering:

TIMESTAMP: A four-byte integer representing seconds UTC since the epoch ('1970-01-01 00:00:00' UTC)

Re: What every programmer should know about time

#28

Post by njl »

andrewcooke wrote: post #19
tseabrooks wrote: post #4

As someone working working on time sensitive code on embedded systems (DVRs that get UTC from the broadcast), I can certainly agree with the issues laid out in the post. As an example: We have some certifications our product must pass and the certification body plays a 4 minute looping broadcast stream with the test condition in it. It turns out I handled the time jump hat occurred when the stream would loop around p…

just to add to the examples here: last week i was writing code to handle calibration data from seismic detectors. these are connected to GPS receivers and so have pretty accurate times. yet when i triggered a calibration it would start 1 minute in the past. somehow the receiver was moving back in time before starting the calibration.... ...or ntpd on the test computer had failed and the machine was a minute fast :o)…

I haven't played with it much, but the dateutil[1] package seems to do some nice stuff.

[1] http://labix.org/python-dateutil

Re: What every programmer should know about time

#29

Post by wvenable »

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.

Re: What every programmer should know about time

#30

Post by wvenable »

codyrobbins wrote: post #20
melvinmt wrote: post #10

One notable addition: relative time is the same for everyone. What I mean by this is that instead of messing with timezones (by trying to guess the user's timezone or even worse, asking for it) in most cases it is sufficient to tell the user something has happened x hours ago, or y days ago. If you're programming in PHP, I can recommend this book: http://www.amazon.com/architects-Guide-Date-Time-Programming...

Ugh, I feel that this is one of the single poorest time-related pratices—from a UX perspective—short of not displaying the time at all. Please don’t follow this advice. It makes it really easy for the developer because there’s no need to deal with time zones and things like DST. However, showing a relative time in many situations is completely opaque. If something happened ‘14 hours ago’, did it happen at lunch time…

I agree! And one of the more useful things you can do with a web app is render time using JavaScript (with an appropriate fallback) and then it will show the timestamp in the user's timezone automatically.
Post reply on HN