Does it matter what state I set if both locations are in the same timezone

I found the solution here.

However, the tzdata source has changed its URI. It is now to be found at: ftp://ftp.iana.org/tz/ or http://www.iana.org/time-zones for more information.

1. Download the updated tzdata-file, in this case, tzdata2012j.tar.gz and extracted it to a temporary folder.

2. SSH into the iPod and copy the extracted files to the iPod. I chose User/Downloads and created a new (temporary) folder tzfix into which I copied everything.

3. After that, compile it with the command: zic southamerica, which takes a few seconds.

4. Then, use the following command to copy this file:

   cp /usr/share/zoneinfo/America/Argentina/Buenos_Aires /usr/share/zoneinfo/America/Buenos_Aires

5. Testing date "+%z" and date "+%Z" both return correct values, now: -0300 and ART

Finally! I can set the clock to the correct time without Twitter refusing to login and Google Authenticator throwing wrong auth codes.

Edit: There is another separate database for the time which needs to be updated: the ICU database. It uses the same tzdata and needs to be compiled into /usr/share/icu/icudt40l.dat. This is necessary so that the clock and calendar apps show the correct time.

You have have the timezone set incorrect. To see if it works at all use some others (the extremes):

$ TZ=Pacific/Midway date
Mon Sep 28 20:42:02 SST 2015
$ TZ=Pacific/Kiritimati date
Tue Sep 29 21:42:48 LINT 2015

and if you double check your entry against the list you can see you're missing an underscore in the value of $TZ.

So try

$ TZ=America/Los_Angeles date

and see if your problem persists.

I haven't found any policy for the naming of the timezones, but spaces are never in them and replaced by underscore, but sometimes with a dash. It is probably best to look it up and copy/paste the value, something you, or your source didn't.