Opened 3 years ago

Closed 3 years ago

#11563 closed defect (fixed)

inaccuracy with conversion to unix timestamps

Reported by: dsd Owned by: martin.langhoff
Priority: normal Milestone: Not Triaged
Component: ofw - open firmware Version: not specified
Keywords: Cc: martin.langhoff
Blocked By: Blocking:
Deployments affected: Action Needed: no action
Verified: no

Description

We are seeing a problem with rtcreset.sig verification when dealing with certain dates. The "current RTC time" field in the rtcreset.sig file matches what is listed in the rtc-timestamp chosen property, but the firmware incorrectly complains that there is a mismatch.

I have narrowed this down to a bug relating to conversion to/from unix timestamps. This demonstrates the issue:

" 20131209T000350Z" decode-timestamp >unix-seconds unix-seconds>

The returned date is 8th December 2013 - it should be the 9th, as it was in the input.

Change History (6)

comment:1 Changed 3 years ago by wmb@…

  • Action Needed changed from never set to test in build
  • Owner changed from wmb@… to Quozl

Fixed by svn 2792 - the leap year calculations were broken.

comment:2 Changed 3 years ago by Quozl

  • Action Needed changed from test in build to approve for release

Reproduced on Q4C11, Q3B23, Q2F05.

Tested fine in Q4C11ja, Q3B23jg, Q2F05jf.

What releases do you need made, Daniel?

comment:3 Changed 3 years ago by dsd

  • Cc martin.langhoff added

That's a question for Martin.

comment:4 Changed 3 years ago by Quozl

Fixed in Q4C12.

comment:5 Changed 3 years ago by Quozl

  • Action Needed changed from approve for release to communicate
  • Owner changed from Quozl to martin.langhoff

comment:6 Changed 3 years ago by Quozl

  • Action Needed changed from communicate to no action
  • Resolution set to fixed
  • Status changed from new to closed

Released in Q2F06 and Q3C01.

Note: See TracTickets for help on using tickets.