Earlier quoted context omitted.
Storing everything in UTC is a huge improvement, but is still an imperfect solution because the Tz database changes over time. Suppose you are writing a appointment tracking system, and, at some point before the olson tz database has been updated with this change, the user in the Samoa timezone creates an future appointment for Jun 2, 2012. That would be stored in UTC. Now, you upgrade the olson TZ database file on y…
Yes, you're right. In cases like that you should store future events as local time, and wait until a resonable time before the event (e.g. a week) to convert from local to UTC. Then you will have (hopefully) an updated tzdata file.
Samoa cancels Friday 30th and travels one day forward in time
21–30 of 37 posts
Re: Samoa cancels Friday 30th and travels one day forward in time
#22Re: Samoa cancels Friday 30th and travels one day forward in time
#23I'm quite curious if local churches will follow along with the change. I know Jews wouldn't, and I doubt Muslims would, but I don't think there are any Jews there anyway, not sure about Muslims.
Re: Samoa cancels Friday 30th and travels one day forward in time
#24Earlier quoted context omitted.
Yes, you're right. In cases like that you should store future events as local time, and wait until a resonable time before the event (e.g. a week) to convert from local to UTC. Then you will have (hopefully) an updated tzdata file.
what? no, that is a horribly convoluted solution to account for a rare edge case. store UTC and an olson string, and if people live in an area where the dates change, it is their responsibility to move their appointments. if you want to be really nice, you could run a batch job to switch all effected events a day forward.
Events in the future are commonly scheduled relative to what the time is going to be in a specific place, regardless of how the tz rules change in the meantime. Automated actions in the future, however, may well need to be fixed to a UTC time. In short: you need to think about how your system will actually be used, and possibly store values differently depending on how they will be used.
On no account ever use a raw UTC+n offset.
Re: Samoa cancels Friday 30th and travels one day forward in time
#25Who decided to cancel Friday ? Surely there would have been greater agreement for cancelling Monday.
Re: Samoa cancels Friday 30th and travels one day forward in time
#26Samoa will do anything to make it easier to trade with Australia, including switching what side of the road drivers should use. It's getting a little ridiculous.
Re: Samoa cancels Friday 30th and travels one day forward in time
#27I'm quite curious if local churches will follow along with the change. I know Jews wouldn't, and I doubt Muslims would, but I don't think there are any Jews there anyway, not sure about Muslims.
What's to follow? It's just a one-time change that makes a lot of sense given their location. They aren't permanently getting rid of Friday. Besides, Hebrew and Muslim calendars are lunar-based and I would imagine not affected by this.
I'm not super familiar with the Muslim rules, but I know the Jewish rules have their own date line that does not correspond to the international one.
I don't know what the Christian rules are about the international date line and that's what I was asking.
Re: Samoa cancels Friday 30th and travels one day forward in time
#28Re: Samoa cancels Friday 30th and travels one day forward in time
#29I'm quite curious if local churches will follow along with the change. I know Jews wouldn't, and I doubt Muslims would, but I don't think there are any Jews there anyway, not sure about Muslims.
Why not? It's arbitrary anyways--as the article mentions the same place previously switched (which means if the Jews didn't like change they would still be on the time that everyone is now switching back to).
My question was what does Christianity do, and I guess no one here knows.