%j is not padded by zeros!

[Haisam Ido]

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.

[Haisam Ido]

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.

[Sami Samhuri]

Fixed, thanks for the report.

[Sami Samhuri]

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

[Haisam Ido]

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.

[Sami Samhuri]

Ah, I see what you mean. This is how JavaScript behaves. new Date('2013-04-09T15:16:00.000Z') will return a date in the current timezone. There isn't anything I can do about that, it is up to you to maintain the timezone in this case. By the time strftime receives this Date object it has no way of knowing the time zone of the string used to construct it.

-s

On 2013-04-07, at 8:26 PM, Haisam Ido [e-mail] wrote:

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.

—
Reply to this email directly or view it on GitHub.

[Haisam Ido]

I see. Thanks for the feedback.

[Sami Samhuri]

No problem!

[Haisam Ido]

BTW, new Date('2013-04-09T15:16:00.000Z').getTime() will always return unix
time in UTC/Z/GMT

On Sun, Apr 7, 2013 at 11:30 PM, Sami Samhuri [e-mail]:

Ah, I see what you mean. This is how JavaScript behaves. new
Date('2013-04-09T15:16:00.000Z') will return a date in the current
timezone. There isn't anything I can do about that, it is up to you to
maintain the timezone in this case. By the time strftime receives this Date
object it has no way of knowing the time zone of the string used to
construct it.

-s

On 2013-04-07, at 8:26 PM, Haisam Ido [e-mail] wrote:

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.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/22#issuecomment-16030902
.