Closed erikjung closed 9 years ago
After digging into the UTC issue and concluding that it all came down to the format of the string input (and how the native Date.parse
treats it), I simplified the helper to not do any UTC conversion.
If the helper is used with a localized string format like April 27, 2015
, it will result in the correct timezone offset being used.
If the helper is used with a format that includes time information (for example, 2015-04-27T23:39:35.624Z
), it will result in the correct timezone offset being used.
If the helper is used with a format that doesn't include time information (for example, 2015-04-27
), it will result in an assumption of UTC.
Do we want to take this further and make it accept any format while retaining the local timezone offset?
@erikjung, I think what you've described sounds great. But maybe we could include a summary of that info in the comments for the helper to benefit future generations?
— Sent from Mailbox
On Mon, Apr 27, 2015 at 5:11 PM, Erik Jung notifications@github.com wrote:
After digging into the UTC issue and concluding that it all came down to the format of the string input (and how the native
Date.parse
treats it), I simplified the helper to not do any UTC conversion. If the helper is used with a localized string format likeApril 27, 2015
, it will result in the correct timezone offset being used. If the helper is used with a format that includes time information (for example,2015-04-27T23:39:35.624Z
), it will result in the correct timezone offset being used. If the helper is used with a format that doesn't include time information (for example,2015-04-27
), it will result in an assumption of UTC.Do we want to take this further and make it accept any format while retaining the local timezone offset?
Reply to this email directly or view it on GitHub: https://github.com/cloudfour/fabricator/pull/12#issuecomment-96855117
Works with optional date value input and format hash. Closes #10