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

111–120 of 133 posts

Re: What every programmer should know about time

#111

Post by wnoise »

cbr wrote: post #96
CamperBob wrote: post #62

Earlier quoted context omitted.

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?

Technically, overflow of signed integers invokes undefined behavior (or possibly implementation defined. In my copy of a draft standard overflow is given as an example of undefined behavior, but 6.3.1.3 say implementation defined). In practice, it's the same bit values as unsigned integers, which does the right thing in this case.

Re: What every programmer should know about time

#112

Post by [deleted] »

jrockway wrote: post #97
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 t…

[deleted]

Re: What every programmer should know about time

#113

Post by enneff »

qntm wrote: post #104
_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.

This seems like it would cause more problems than it solves. "It's 10:00 here in London. I need to call someone in New York, what time is it there?" "10:00, same as it is everywhere in the world." "So... is now a good time to call them?" "I have no idea."

I'd imagine it would be much easier to remember "business hours in NYC are between 1200 and 2030 UTC," than remembering the time difference and applying a translation every time.

Re: What every programmer should know about time

#114

Post by cdcarter »

matwood wrote: post #21
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.

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.

Time without a time zone is not meaningless. I don't need my calendar to be aware of when in the day the other side of the phone call is happening. I just want to enter "Dinner at 8pm" and have dinner stay at 8pm. This is one situation where I do not want my computer to get unnecessarily smarter than me. Just DWIM.

Re: What every programmer should know about time

#115

Post by viraptor »

cdcarter wrote: post #114
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.

Time without a time zone is not meaningless. I don't need my calendar to be aware of when in the day the other side of the phone call is happening. I just want to enter "Dinner at 8pm" and have dinner stay at 8pm. This is one situation where I do not want my computer to get unnecessarily smarter than me. Just DWIM.

It still depends on where you have the dinner. If you have a dinner at 8pm in UK, you could leave France after 8pm and arrive for your dinner at 8pm again. What would you expect to happen - get the alarm twice?

What if you actually wanted to call someone before their dinner and that's why you put the event in? If that person was in France in this scenario, you'd want to call them before 7pm UK time instead. Calendars can't guess the context - location of the event depends completely on what you put in.

Re: What every programmer should know about time

#116

Post by viraptor »

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.

Don't you get exactly the same problem when you store timezones? CET always stays == UTC + 1 hour. So there's no difference whether you store 8 CET or 7 UTC, because some country may decide it's not in CET at that time anymore... Only storing the actual location would save you if you're thinking about dates in far future.

Then again, you'd have to somehow verify what's the time in that location at that point.

Re: What every programmer should know about time

#117

Post by hammerdr »

stoney wrote: post #55
caf wrote: post #35

Earlier quoted context omitted.

That doesn't sound at all logical to me . The phone conference is scheduled for a particular time, eg 10am in Montreal. The other meeting participants do not care that it is now 10am in Mombasa, where your phone happens to be at the moment - they will not be at the meeting for another 7 hours anyway. Your other way also allows for the same event to happen twice, at different times, which is entirely unexpected.

Yes, very true. Doesn't work very well for events where people are attending from multiple time zones. I was thinking more of events that I attend in person. But I'll use the paper diary example again - if I was in Mombassa and was due to have a phone conference at 10am Montreal time, I would write "6pm - Phone conference" in my diary (assuming that is indeed the correct local time). And in your example, yes, it woul…

Alternatively, we could all just use UTC+0 and never worry about time zones again! :)

Re: What every programmer should know about time

#118

Post by eru »

jrockway wrote: post #110
eru wrote: post #103

Earlier quoted context omitted.

As an aside, have you thought about the effects of DST on train schedules? In Germany, for example, they literally stop the trains for an hour when the clocks go backwards and let them all run a nominal hour late when they are going forward.

Very interesting. I didn't realize that an hour made much of a difference to Deutsche Bahn's schedules, however :)

Sadly, not. And I've done some scheduling work for them.

Re: What every programmer should know about time

#119

Post by laut »

"Other timezones can be written as an offset from UTC. Australian Eastern Standard Time is UTC+1000. e.g. 10:00 UTC is 20:00 EST on the same day."

Every programmer should know about DST. Offsets are not always enough.

When it's winter north of the equator, some countries are on summer time (DST) south of the equator.

Re: What every programmer should know about time

#120

Post by wvenable »

viraptor wrote: post #116
wvenable wrote: post #29

Earlier quoted context omitted.

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.

Don't you get exactly the same problem when you store timezones? CET always stays == UTC + 1 hour. So there's no difference whether you store 8 CET or 7 UTC, because some country may decide it's not in CET at that time anymore... Only storing the actual location would save you if you're thinking about dates in far future. Then again, you'd have to somehow verify what's the time in that location at that point.

I don't store timezone offsets, I store the timezone strings and they are pretty granular. Users can choose the most appropriate timezone from 448 possibilities.
Post reply on HN