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

Time zone news

time.is

Post reply on HN
Print view View original

71–80 of 85 posts

Re: Time zone news

#71

Post by pwg »

mikestew wrote: post #54
protomyth wrote: post #8

Earlier quoted context omitted.

I wish people would quit repeating the farmer myth. No farmer I have met wants daylight savings time. Look at Indiana for some perspective. Farm animals do not have watches.

Just because Indiana doesn't have DST now (for most of the state, anyway) doesn't mean they've always never had it. There was DST when I was growing up in the 70s, and they got rid of it long after agriculture was no longer the primary industry in Indiana. Having grown up in Indiana farm country, I'm of the opinion that "DST because farmers" has always been a myth. One gets up with the sun no matter the time. You qui…

> So we've eliminated the farmer myth, why do we have DST?

One likely possibility is the "but that is the way it has always been done" response (http://www.jeffbridges.com/because.html).

Re: Time zone news

#72

Post by bostonpete »

BookmarkSaver wrote: post #15
bostonpete wrote: post #11

Earlier quoted context omitted.

In Northern areas, there's a lot of practical value that gets overlooked. In Boston, the sun is rising close to 5:00 AM as it is at the height of summer. Without daylight savings time, it would be rising at 4:00 AM. I think most people would rather have extended daylight late in the day than have all that extra sunlight wasted when we're sleeping. The counter to that is -- well, let's always stick with daylight savin…

> For example, sunset is a little after 4:00 PM in Boston in late December. If we stuck with daylight savings time, it'd be a little after 3:00. This seems backwards. Sunset would be after 5 if they kept daylight savings. I used to live in Boston, and I despised how early the sun would set. It made getting off of work demoralizing. I always liked the idea of just switching to Atlantic time. Whatever the case may be,…

You're right, I got it backwards. The problem would be that kids would be walking to school in the dark -- not any less of a problem though.

As it is sunrise is after 7 in the winter (it'd be after 8). In New York it would be even later since they're further west.

Re: Time zone news

#73

Post by mjevans »

magicalist wrote: post #53
bostonpete wrote: post #11

Earlier quoted context omitted.

In Northern areas, there's a lot of practical value that gets overlooked. In Boston, the sun is rising close to 5:00 AM as it is at the height of summer. Without daylight savings time, it would be rising at 4:00 AM. I think most people would rather have extended daylight late in the day than have all that extra sunlight wasted when we're sleeping. The counter to that is -- well, let's always stick with daylight savin…

> For example, sunset is a little after 4:00 PM in Boston in late December. If we stuck with daylight savings time, it'd be a little after 3:00 This is backwards. Sunset would be later, at about 5:15PM (the problem would be late sunrise in the morning). For instance, sunset on October 31 in Boston this year will be 5:40PM EDT, but on November 1 it will be 4:39 EST. You did, however, demonstrate another fantastic reas…

More than that; you're forgetting about locale specific DST rules. It is increasingly common for DST to be observed at different times in different countries. Then there are also places (such as Arizona) that don't observe DST at all as well.

This is a mess that can only be solved by isolating 'meeting' and 'appointment' times from local time. For local time you might specify X on date Y, but the software should, at the time of input, convert that to an actual hard time (in UTC).

Re: Time zone news

#75

Post by sdkmvx »

phirschybar wrote: post #22
dijit wrote: post #3

Is there still a valid reason to have timezones altering between states? is it just for agriculture? While we're, talking about changing time monitoring systems, can't we have 13 months with 28 days each? (and an extra day every 4 years added on to december?) :( Simple things, but that would allow us to follow the lunar cycle.

Ha. What is your solution for existing birthdays?

Not that I would advocate confusing matters by changing the calendar again, but you just move the birthdays same as last time.

From Wikipedia: George Washington (February 22, 1732 [O.S. February 11, 1731] – December 14, 1799)

Notice the year is different. In the British Empire before 1752, March 25th was the first day of the year. March 24, 1751 was the day before March 25, 1752. Then September 2, 1752 was the day before September 14, 1752 The last day of 1752 was December 31, and the calendar has continued how we consider normal ever since.

The British custom of starting the tax year on April 6th survives as a relic of the old calendar (March 25th plus the missing 12 days in 1752).

Re: Time zone news

#76

Post by 0x0 »

scrollaway wrote: post #67
0x0 wrote: post #35

Earlier quoted context omitted.

Lots of events needs to be scheduled in local time. If your calendar app stores a given UTC timestamp for your meeting with a customer on friday at 5PM and the time zone rules database change inbetween, you're going to have an angry customer.

And what would meta-metadata about the datetime solve? What you're looking for is faster updates to timezone libraries. And for governments to stop being idiots — "I'm delaying DST because it inconveniences me", pah, what a load of garbage. It's a symptom of how much DST sucks. If anything, this couldve been a good occasion to repel DST in turkey.

If you stored it in the DB as "2015-10-30 17:00:00 SOMETIMEZONE" then it would be unambiguous when the event is going to happen. If you stored an UTC timestamp, well, then you'd get two different values depending on whether you had the updated tzdata or not when the value was entered and converted to a timestamp.

If you think this problem can be solved by declaring today's version of tzdata immutable and final, then I'm afraid you're not being realistic. Timezones, DST rules, country borders will change and always have.

Re: Time zone news

#77

Post by 0x0 »

scrollaway wrote: post #66
jarcoal wrote: post #25

Situations like Turkey's DST extension reminds me why storing dates in UTC with no further information is not good enough.

It is good enough. When converted to the local timezone, the library would know to offset the date properly - it just has to be told to do it. I don't see the problem.

Store the starting point for a meeting scheduled for October 30th, 2050, at 5pm local time in Pyongyang.

Are you sure the value of UTCunixtime("2050-10-30 17:00:00 Pyongyang") today will be correct in 2050? What if this record was created last year? (hint: the timezone was recently changed).

Remember, the meeting is supposed to happen at 17:00 local time on that day no matter what.

Re: Time zone news

#78

Post by cbd1984 »

hellbanner wrote: post #6
dijit wrote: post #3

Is there still a valid reason to have timezones altering between states? is it just for agriculture? While we're, talking about changing time monitoring systems, can't we have 13 months with 28 days each? (and an extra day every 4 years added on to december?) :( Simple things, but that would allow us to follow the lunar cycle.

I asked farmers about this. They said it was stupid now that we have electricity. And even then, with the shorter days.. it was still stupid. (I'm quoting them)

Also, the extra hour of daylight utterly destroys the crops.

Re: Time zone news

#79

Post by scrollaway »

0x0 wrote: post #77
scrollaway wrote: post #66

Earlier quoted context omitted.

It is good enough. When converted to the local timezone, the library would know to offset the date properly - it just has to be told to do it. I don't see the problem.

Store the starting point for a meeting scheduled for October 30th, 2050, at 5pm local time in Pyongyang. Are you sure the value of UTCunixtime("2050-10-30 17:00:00 Pyongyang") today will be correct in 2050? What if this record was created last year? (hint: the timezone was recently changed). Remember, the meeting is supposed to happen at 17:00 local time on that day no matter what.

Ah, I understand better now. Though this wouldn't be a problem if timezone names weren't reused, right? eg. "2050-10-30 17:00:00 Pyongyang" would correspond to "2050-10-30 17:00:00 Pyongyang2" just fine.

Re: Time zone news

#80

Post by scrollaway »

0x0 wrote: post #76
scrollaway wrote: post #67

Earlier quoted context omitted.

And what would meta-metadata about the datetime solve? What you're looking for is faster updates to timezone libraries. And for governments to stop being idiots — "I'm delaying DST because it inconveniences me", pah, what a load of garbage. It's a symptom of how much DST sucks. If anything, this couldve been a good occasion to repel DST in turkey.

If you stored it in the DB as "2015-10-30 17:00:00 SOMETIMEZONE" then it would be unambiguous when the event is going to happen. If you stored an UTC timestamp, well, then you'd get two different values depending on whether you had the updated tzdata or not when the value was entered and converted to a timestamp. If you think this problem can be solved by declaring today's version of tzdata immutable and final, then…

> by declaring today's version of tzdata immutable and final

It doesn't have to be immutable and final, it can simply be versioned then :) cf what I said in my other reply, if you create a new timezone every time you change it, it seems you don't have that problem.

Post reply on HN