fix the failing date tests introduced with the latest timezonedb update

Derick confirmed on irc that the new/current behavior is the correct and that the tests should be updated to reflect it
This commit is contained in:
Ferenc Kovacs 2014-08-12 10:34:54 +02:00
parent 84a4041ba4
commit 39dd715382
3 changed files with 10 additions and 10 deletions

View File

@ -95,18 +95,18 @@ result = Monday 2037-10-05 00:00:00 NZDT
wanted = Monday 00:00:00
Australia/Adelaide
ts = Friday 1971-01-01 17:17:17 CST
result = Monday 1971-01-04 00:00:00 CST
ts = Friday 1971-01-01 17:17:17 ACST
result = Monday 1971-01-04 00:00:00 ACST
wanted = Monday 00:00:00
Australia/Darwin
ts = Monday 1971-03-29 17:17:17 CST
result = Monday 1971-04-05 00:00:00 CST
ts = Monday 1971-03-29 17:17:17 ACST
result = Monday 1971-04-05 00:00:00 ACST
wanted = Monday 00:00:00
Australia/Perth
ts = Friday 1971-01-01 17:17:17 WST
result = Monday 1971-01-04 00:00:00 WST
ts = Friday 1971-01-01 17:17:17 AWST
result = Monday 1971-01-04 00:00:00 AWST
wanted = Monday 00:00:00
America/Aruba

View File

@ -233,8 +233,8 @@ result=Saturday 1970-01-03 00:00:00 CAT 0
wanted=Saturday 00:00:00
TZ=Asia/Kashgar - Is it OK for this to be 3 AM? yes
tStamp=Thursday 1980-04-24 17:17:17 KAST 0
result=Thursday 1980-05-01 03:00:00 CST 0
tStamp=Thursday 1980-04-24 17:17:17 XJT 0
result=Thursday 1980-05-01 00:00:00 XJT 0
wanted=Thursday 03:00:00
TZ=Indian/Christmas - Is it OK for this to be 7 AM? Note: does

View File

@ -39,5 +39,5 @@ datestr 10:00:00 AM July 1 2005 UTC
Setting TZ
input 10:00:00 AM July 1 2005
strftime 10:00:00 AM July 1 2005 EST +1000
datestr 10:00:00 AM July 1 2005 EST
strftime 10:00:00 AM July 1 2005 AEST +1000
datestr 10:00:00 AM July 1 2005 AEST