Hi,
There's multiple issues with the way '%s' is handled, starting with the less
controversial (%s):
Time.strptime('0', '%s')
=> 1969-12-31 18:00:00 -0600
If '%s' is meant to imply UTC, then clearly there's a bug here.
After this patch series:
Time.strptime('0', '%s')
=> 1970-01-01 00:00:00 +0000
However, the timezone can be overriden, and in other languages like C and Perl,
it's perfectly fine to use '%s %z'. In fact, Ruby already works fine with
'%s %z', for strftime:
Time.at(0).localtime('+01:00').strftime('%s %z')
=> "0 +0100"
But it doesn't with strptime():
Time.strptime('0 +0100', '%s %z').strftime('%s %z')
=> "0 -0600"
After this series:
Time.strptime('0 +0100', '%s %z').strftime('%s %z')
=> "0 +0100"
The same happens with DateTime.
Rubinious has been fixed already:
Since the RubySpec standard library tests are moving towards the spec tests in
rubysl, Ruby is now failing these:
Time#strptime parses number of seconds since Unix Epoch as UTF FAILED
Expected -21600
to equal 0
Time#strptime parses number of seconds since Unix Epoch with timezone FAILED
Expected "1969-12-31 18:00:00 -0600"
to equal "1970-01-01 01:00:00 +0100"
DateTime#strptime parses seconds and timezone correctly FAILED
Expected "1970-01-01T00:00:00+00:00"
to equal "1970-01-01T01:00:00+01:00"
So why not do the reasonable thing and apply these patches? Nobody woudld be
affected negatively, because not only will '%s' keep working as before, but it
would work better.
Charlie Somerville (1):
datetime: fix strptime '%s %z'
Felipe Contreras (1):
time: fix strptime '%s'
ext/date/date_core.c | 8 ++++++--
lib/time.rb | 3 ++-
test/date/test_date_strptime.rb | 6 ++++++
test/test_time.rb | 2 ++
4 files changed, 16 insertions(+), 3 deletions(-)
···
--
1.8.4-fc