What every programmer should know about time • Hacker News Board

Re: What every programmer should know about time

#91

Post by [deleted] » Mon, Jul 04, 2011, 10:52 AM UTC

CamperBob wrote: post #62

sehugg wrote: post #44

Also beware storing milliseconds in 32-bit quantities (as if you'd ever! but it happens). GetTickCount is the poster child for this class of bugs: http://en.wikipedia.org/wiki/GetTickCount In fact some versions of Windows CE intentionally set this value to (0xffffffff - 10 minutes) before bootup so that bugs were more likely to come out in testing, rather than showing up 42 days after bootup. Also, don't store time i…

You can store milliseconds in 32-bit quantities all you want, if you remember the One True Axiom of Time: never compare tick counts, always subtract and compare to the difference you were looking for. If you do it that way, you can't screw it up, at least in C.

[deleted]

Re: What every programmer should know about time

#92

Post by JonnieCache » Mon, Jul 04, 2011, 11:08 AM UTC

For anyone else who has just learned about UT1 time and wants to know what it's current value is, here's the link:

http://tf.nist.gov/pubs/bulletin/leapsecond.htm

Today, UT1 - UTC = 82ms.

Re: What every programmer should know about time

#93

Post by wladimir » Mon, Jul 04, 2011, 11:35 AM UTC

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!

Unix timestamps are indeed easy and good enough for most cases (isn't the mantra "keep it simple"?), except for calendars/recurring events, as some people have pointed out.

Re: What every programmer should know about time

#94

Post by prima-facie » Mon, Jul 04, 2011, 11:42 AM UTC

> When storing time, store Unix time. It's a single number.

This is BS. ISO-8601 (MySQL time) is way better and is not prone to the 2038 bug. Unix time has 'scalability' issues.

Re: What every programmer should know about time

#95

Post by rvkennedy » Mon, Jul 04, 2011, 11:48 AM UTC

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)…

Watch out for GPS time: it ignores leap seconds, and is currently, exactly fifteen seconds ahead of UTC.

Re: What every programmer should know about time

#96

Post by cbr » Mon, Jul 04, 2011, 11:50 AM UTC

CamperBob wrote: post #62

sehugg wrote: post #44

Also beware storing milliseconds in 32-bit quantities (as if you'd ever! but it happens). GetTickCount is the poster child for this class of bugs: http://en.wikipedia.org/wiki/GetTickCount In fact some versions of Windows CE intentionally set this value to (0xffffffff - 10 minutes) before bootup so that bugs were more likely to come out in testing, rather than showing up 42 days after bootup. Also, don't store time i…

You can store milliseconds in 32-bit quantities all you want, if you remember the One True Axiom of Time: never compare tick counts, always subtract and compare to the difference you were looking for. If you do it that way, you can't screw it up, at least in C.

Really? What if it wraps around? ts1=MAX_INT-40, ts2=20, ts2-ts1 < 0. Or does that actually work out correctly with signed integers in C?

Re: What every programmer should know about time

#97

Post by jrockway » Mon, Jul 04, 2011, 12:16 PM UTC

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…

The article should add a caveat: use UNIX time when you are recording the current time to store for later use. That can always be formatted in the user's current timezone to display back.

When you're inventing a rule system based on local times, as you are above, of course you need to track the rules in the local time zone. That's because the rule is: "do this thing at 9am in my particular local time zone", not "do this thing every 86400 seconds". Keep in mind that this is hard, though, due to the fact that in many local time zones, one hour is missing on one day ("spring forward"), and one hour occurs twice on one day ("fall back"). If you have some event that should be triggered at 1:30am, which 1:30am do you mean? The first 1:30am or the second 1:30am? What about on the "spring forward" day, when 1:30am doesn't occur at all?

Re: What every programmer should know about time

#98

Post by adestefan » Mon, Jul 04, 2011, 12:43 PM UTC

_urga wrote: post #87

In the future, the world will use UTC and sunrise and sunset will happen at different times, relative to where you are.

No they won't. The idea that 12am is night and 12pm is day is pretty well entrenched in society.

Re: What every programmer should know about time

#99

Post by [deleted] » Mon, Jul 04, 2011, 12:55 PM UTC

troels wrote: post #68

lysol wrote: post #27

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)

MySql's datetime fields are not timezone aware. If one client has set one timezone and inserts a value in a datetime field and another client has a different timezone, the value will not be converted.

[deleted]

Re: What every programmer should know about time

#100

Post by lysol » Mon, Jul 04, 2011, 12:55 PM UTC

troels wrote: post #68

lysol wrote: post #27

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)

MySql's datetime fields are not timezone aware. If one client has set one timezone and inserts a value in a datetime field and another client has a different timezone, the value will not be converted.

Not sure that's contradictory to my point about the backend storage. The overall points in the article are correct but its note about how MySQL stores its DATETIMEs is strange, and I'd hate to make people think MySQL is a bad database because of incorrect information, instead of things like the lack of transactional DDL.