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

81–90 of 133 posts

Re: What every programmer should know about time

#81

Post by dirtyaura »

peteretep wrote: post #78
dirtyaura wrote: post #72

> Timezones are a presentation-layer problem! I want to correct this common misconception that UTC is enough. Calendar time with all human traditions involved is more complex than a simple timestamp. The advice above is incorrect for calendar and scheduling apps, or anything that has a concept of a repeating event. An example: we have a weekly meeting occurring 9AM Monday in San Francisco. You are in London and want…

UTC is enough for - as the article suggests - storing a date. Storing a recurring class of dates is - of course - more complicated; but then has anyone ever suggested otherwise?

Maybe nobody explicitly suggested otherwise, but I just wanted to highlight that time is a human concept and in informal context can mean a lot of different kinds of things (e.g. a time of recurring event). When you start formally modeling those, a single timestamp isn't enough.

Re: What every programmer should know about time

#82

Post by rmc »

Another thing to add: When asking people to put in the timezones, don't ask them for a UTC/GMT offset, and the dates that DST starts/ends. Instead ask them for the tzdata format (e.g. "Europe/London"). Then you can localize that wherever you want.

Re: What every programmer should know about time

#84

Post by peteretep »

roel_v wrote: post #76
dirtyaura wrote: post #72

> Timezones are a presentation-layer problem! I want to correct this common misconception that UTC is enough. Calendar time with all human traditions involved is more complex than a simple timestamp. The advice above is incorrect for calendar and scheduling apps, or anything that has a concept of a repeating event. An example: we have a weekly meeting occurring 9AM Monday in San Francisco. You are in London and want…

Yes, very correct! I hope the 'lets just use Unix timestamp because it's easy' mentality will go away soon!

What would you replace it with for storing a single date?

Re: What every programmer should know about time

#85

Post by roel_v »

peteretep wrote: post #84
roel_v wrote: post #76

Earlier quoted context omitted.

Yes, very correct! I hope the 'lets just use Unix timestamp because it's easy' mentality will go away soon!

What would you replace it with for storing a single date?

Depends on the context it's used in. Usually YYYY-MM-DDThh:mm:ss of ISO 8601, explicitly extend it with the UTC timezone (with the + notation), sometimes that plus the local timezone in a separate column/field, sometimes a serialized version of a library representation of a date.

Re: What every programmer should know about time

#86

Post by jen_h »

wladimir wrote: post #73
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.

This literally just happened to a VPS of mine. Time was jumping forwards and back, every second the time could jump an hour ahead and back. Everything screwed up, from log rotation to sessions. My first thought was that this was some kind of prank :-) but seems it was a hardware issue on the parent machine combined with ntpd trying to compensate.

This one was a blast back in the day:

http://kb.vmware.com/selfservice/microsites/search.do?langua...

No need to run the test case, you'd run into it soon enough on a 2.6 kernel on VMWare. ;)

Re: What every programmer should know about time

#88

Post by jen_h »

jodrellblank wrote: post #33
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.

Ooh, such as?

The most fun one I ever found was a situation where a daemon analyzing & forwarding traffic through a bridged interface would lock up & stop passing traffic when you popped backwards and forwards through time on the box.

Re: What every programmer should know about time

#89

Post by dirtyaura »

roel_v wrote: post #85
peteretep wrote: post #84

Earlier quoted context omitted.

What would you replace it with for storing a single date?

Depends on the context it's used in. Usually YYYY-MM-DDThh:mm:ss of ISO 8601, explicitly extend it with the UTC timezone (with the + notation), sometimes that plus the local timezone in a separate column/field, sometimes a serialized version of a library representation of a date.

UTC is fine for single events. For the recurring events, UTC + timezone alone is useless, you need to know the DST rules too to make correct calculations over the DST changes.

vCal has spec for DST rules, but you don't want to store them for every event. You store a location or "DST zone" of your event and have DST rules in separate database (they need to be updated as DST rules can change)

When I worked on calendar applications, there was not commonly agreed way to transfer DST zones between systems, but single DST rules could be transferred as part of vCal entry.

Microsoft apparently implemented their own integer code for every "DST zone" and used it to transfer events correctly between Microsoft systems (e.g. sending meeting invitations by email from Outlook to Outlook). Things might have changed since I worked on this area, I haven't checked the current status.

Re: What every programmer should know about time

#90

Post by justincormack »

wladimir wrote: post #73
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.

This literally just happened to a VPS of mine. Time was jumping forwards and back, every second the time could jump an hour ahead and back. Everything screwed up, from log rotation to sessions. My first thought was that this was some kind of prank :-) but seems it was a hardware issue on the parent machine combined with ntpd trying to compensate.

You should read this article (also applies to other VMs) http://www.vmware.com/files/pdf/Timekeeping-In-VirtualMachin...

There are a lot of issues that can happen because of this...

Post reply on HN