Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Timezone calculator.
#11
PLEASE NOTE:

1) Two minor modifications in SOLID CAPS have been edited to the original specifications of the challenge, for clarity.

2) Currently the requirements call for handling a date as input and a calculated date as output. This implies a tedious date validation as well as rather complicated date arithmetic.

So, for those of you who prefer not dealing with dates, you may eliminate the date on input and output, and substitute on output a message indicating a day adjustment of 0, +1, or -1.

Example for using optional day adjustment:
If Input #1 has GMT-6 at 23:00,
and Input #2 wants results for GMT-4,
then the output time will be 01:00 with a day adjustment of +1.
Get it?
*****
Reply
#12
Quote:My son is in Japan this week participating in a Robocup (robots that play soccer) competition.

damn lucky punk
Reply
#13
Quote:Boy, do we have a can of worms regarding timezones.

I consulted my Encyclopaedia Britannica and World Book Encyclopedia and they both define 24 standard timezones.

There are numerous exceptions, but for this challenge, we will use the 24 timezones on the following list. I have included principal country/city names.

Also for this challenge, we will ignore the issue of daylight savings or summer time. It becomes almost impossible for our program to determine if the subject timezome uses daylight savings, when it starts and ends, and whether it advances one hour or two. Therefore, we will leave this daylight time adjustment up to the user of the program.

TIMEZONES:
GMT = London
GMT - 1 = Reykjavik
GMT - 2 = Greenland
GMT - 3 = Rio de Janeiro, Brazil
GMT - 4 = Santiago de Chile
GMT - 5 = New York
GMT - 6 = Chicago
GMT - 7 = Denver
GMT - 8 = Seattle
GMT - 9 = Alaska
GMT -10 = Honolulu
GMT -11 = Midway Island
GMT -12 (does not exist, see GMT +12)

continuing in a circle around the world............
GMT +12 = New Zealand
GMT +11 = Solomon Islands
GMT +10 = Sydney
GMT + 9 = Tokyo
GMT + 8 = Hong Kong, and China
GMT + 7 = Bangkok
GMT + 6 = Omsk, Russia
GMT + 5 = Karachi
GMT + 4 = Stalingrad
GMT + 3 = Moscow
GMT + 2 = Cairo
GMT + 1 = Berlin

Comments?
*****

It's easy to add the non-standard timezones. DST is harder, since that splits Australia up into a real mess. Darwin is GMT +9:30. So is Adelaide. Darwin and the NT do not have DST. Adelaide and SA do. Brisbane in QLD does not have DST, NSW, Vic and Tas have DST. WA does not. For ease of reading, I won't include the ACT, which is surrounded by NSW anyway.

During the winter time of the year, such as now, we have:

GMT +8:00 WA
GMT +9:30 SA, NT
GMT +10:00 QLD, NSW, ACT, VIC, TAS

During summer months:
GMT +8:00 WA
GMT +9:30 NT
GMT +10:00 QLD
GMT +10:30 SA
GMT +11:00 NSW, ACT, VIC TAS

Then what about the middle east? Last I heard, the whole area is one time zone, instead of 5 or 6.

The former USSR? 11 zones...

My opinion would be the following: include the GMT +/- x:30 non standard timezones. Don't include DST.

BTW, I live in SA. That makes me GMT +9:30 atm.

EDIT: According to http://wwp.greenwichmeantime.com/info/timezone.htm, Kiribati islands is over a day behind New Zealand. So Thursday in NZ is still Tuesday in Kiribati Is.

>anarky
Screwing with your reality since 1998.
Reply
#14
anarky,

Thanks for your exhaustive analysis of the timezone exceptions in Australia. As you can well imagine, no one is going to want to program these hairy exceptions into his program for Australia and any other non-standard timezone --- even if he happens to live there.
*****
Reply
#15
Hey guys,
Is anybody working on a solution for this challenge?

Heck, my family all say it's easy, that they can do it in their head. How many hours from New York (GMT-5) to Berlin (GMT+1)? That's easy: take the 5 and add the 1, so it's 6 hours away. And when you add the 6 hours to New York time and it goes passed midnight, then the Berlin date is +1 that of NY.

Yeah, yeah, yeah, but program the sucker to handle all 24x23 from/to timezone combinations!!!!!

I've got a program in the works, but I'm having trouble deciding whether to go clockwise around the world's timezomes, or counter-clockwise. The way the sample table is set up, it's going counter-clockwise.
Example: from New York (GMT-5) to Tokyo (GMT-9) is 14 timezones clockwise and 10 counter-clockwise. If I go clockwise I add 14 hours to NY time, and for counter-clockwise I subtract 10 hours. Whick is easier or best?
And then what if the from and to are both GMT+ or both GMT- or from a GMT+ to a GMT-, then what's the general rule?

Have any of you guys thought about these issues?
*****
Reply
#16
I would say the simplest way (just off the top of my head, at least) would be to convert the local time to GMT (by adding or subtracting the offset, except use the opposite sign as specified) and then converting from that GMT-relative time to the remote time (by adding or subtracting offset from GMT again, but with the correct sign).
Reply
#17
The whole goal behind this program is to find out what time it is and where at any given time. Not what timezone it is. Maybe I'm tired and didn't fully understand your post. Maybe I'm not.

I'll work on it tomorrow for you. It's very simple.

>anarky - Overworked: Underpayed.
Screwing with your reality since 1998.
Reply
#18
Quote:I would say the simplest way (just off the top of my head, at least) would be to convert the local time to GMT (by adding or subtracting the offset, except use the opposite sign as specified) and then converting from that GMT-relative time to the remote time (by adding or subtracting offset from GMT again, but with the correct sign).

DrV,
Not a bad idea. I understand it as a two step operation. First adjust the time at the FROM timezone to GMT 0. Second, adjust that for the number of hours from GMT 0 to the target TO timezone.
I think it could work.

I already have a solution which I'm in the process of testing, which basically does the operation in one step per each of the following 4 from/to cases:
FROM GMT+ - TO GMT+
FROM GMT+ - TO GMT-
FROM GMT- - TO GMT+
FROM GMT- - TO GMT-

Excluding the input and validation of the 3 input fields,
and excluding defining the timezone table,
the actual logic takes 30 lines of very simple code. Determining how do to this logic has taken me several days of analysis.

Also, it turns out that the timezone table is only needed to lookup and print the name of the city at each timezone. It is not needed for the logic, at least not in my version.


ANARKY,
Your right about the goal.
Let me try to express it a little clearer with this example:

If I'm in New York (GMT-5), and the time is 17:00,
What time is it in Tokyo (GMT+9)? --- Answer is 07:00
And, is it the same date? ------------- Answer is: add 1 to NY date.
BTW, the difference in time from NY is +14 hours.
*****
Reply
#19
Quote:If I'm in New York (GMT-5), and the time is 17:00,
What time is it in Tokyo (GMT-9)? --- Answer is 07:00
I think you mean GMT+9 for Tokyo. . . Smile
974277320612072617420666C61696C21 (Hexadecimal for those who don't know)
Reply
#20
Quote:
Moneo Wrote:If I'm in New York (GMT-5), and the time is 17:00,
What time is it in Tokyo (GMT-9)? --- Answer is 07:00
I think you mean GMT+9 for Tokyo. . . Smile

Thanks, rpg,
You're absolutely right. :oops: I make the same mistake when I'm testing --- no wonder I get the wrong answer. :roll:

I'm glad someone is paying attention. Big Grin

BTW, your name, rpgfan3233, it couldn't possibly be rpg for RPG (Report Program Generator)?
*****
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)