Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

%j is not padded by zeros! #22

Closed
haisamido opened this Issue · 8 comments

2 participants

@haisamido

According to the 'Supported Specifiers' section:

j is the day of the year, padded to 3 digits (001-366)

while:

console.log(strftime('%Y-%jT%H:%M:%S', new Date('2013-04-09T15:16:00.000Z')));

returns without a padded zero:

2013-99T11:16:00

but should be:

2013-099T15:16:00

It also appears that the function doesn't preserve the timezone but converts it to the browsers timezone.

@haisamido

I believe if you replace lies 116, 117 and 118 in strftime.js:

      var y=new Date(d.getFullYear(), 0, 1);
      var day = Math.ceil((d.getTime() - y.getTime()) / (1000*60*60*24));
      return day;

with

     return pad( Math.floor((new Date(d) - new Date((new Date(d)).getFullYear(), 0, 0))/(1000 * 60 * 60 * 24)), 3);

should pad the day of year correctly. However, this doesn't take care of the timezone issue.

@samsonjs samsonjs closed this in 2e6443f
@samsonjs
Owner

Fixed, thanks for the report.

@samsonjs
Owner

Do you have an example I can test with for the timezone issue? It behaves correctly here (PST).

@haisamido

Try a date of this type: '2013-04-09T15:16:00.000Z' where Z is Zulu time, i.e. GMT, i.e. UTC. In EST it should be in 2013-04-09T10:16:00.000 (5 hours difference) but what should be returned is the date and time formated for the originally provided timezone and not changed to the local time zone.

Of course, I could be doing something wrong.

One would not see this problem if one's machine is set to UTC/GMT/Z because in that case local is the same as UTC.

@samsonjs
Owner
@haisamido

I see. Thanks for the feedback.

@samsonjs
Owner

No problem!

@haisamido
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.