Introduce an UTC mode simpler than #168 #326
Conversation
Codecov Report
@@ Coverage Diff @@
## master #326 +/- ##
=====================================
Coverage 100% 100%
=====================================
Files 32 39 +7
Lines 386 445 +59
Branches 53 69 +16
=====================================
+ Hits 386 445 +59
Continue to review full report at Codecov.
|
|
I am considering a plugin with this implementation, but I am not sure, if it fits such pervasive implementation. The, |
Additions:
* Constructor accepts a boolean flag to enable the UTC mode: { utc: true }.
* Method utc() returns a clone of the instance in the UTC mode.
* Method local() returns a clone of the instance in the non-UTC (local) mode.
* Method isUTC() checks, if the instance is in the UITC mode.
* Method utcOffset() returns the time zone offset to UTC consistently with Date.prototype.getTimezoneOffset()
Differences to the "normal" (local) dayjs mode:
* Assume UTC as the time zone of the string passed to the constructor - for example, "2018-10-28" will be parsed as "2018-10-28T00:00:00Z". *But only if the time zone is omitted.* If you end the string tith a TZ offset - "2018-10-28T00:00:00+02:00", it will be retained and the whole date will be converted to UTC, when iniitalizing the datejs object.
* Methods returning the date parts like year(), month() etc. return UTC parts using Date.propertotype.getUTC* methods.
* Methods manipulating the date - set() - work with the UTC values of the date parts, as the getters above.
* The format() method always formats the time zone as "+00:00".
* The utcOffset() method always returns zero.
|
I wonder if you liked more the interface: dayjs.utc('2018-09-25')instead of the current: dayjs('2018-09-25', { utc: true })I introduced the latter, because static methods may feel like having a global effect on |
|
I prototyped an implementation of the UTC mode as a plugin the branch https://github.com/prantlf/dayjs/commits/utc-mode-plugin. It is rather an example, what should not be a plugin :-) Leaving Plugins are supposed to extend Day.js with additional functionality. Not to copy & paste I tried to put the differences between the local time zone and UTC modes on the interface. Basically, it is the UTC mode does not feel such an exotic feature, or to increase the size so much, to leave it out of the core library. |
|
Any update on when this will be merged and released? |
|
Eventually , I added the static method dayjs.utc('2018-09-25')It fits the purpose of Day.js to help migration from Moment.js. And the code is shorter, that the constructor option. |
|
I think put in a plugin is better, #517. Referenced some logic and test suits from this PR, great thanks. |
The "UTC mode" means, that he constructor assumes the UTC date in the input string and the instance methods return and accept date parts (year, month etc.) in UTC.
Additions
{ utc: true }.utc()returns a clone of the instance in the UTC mode.local()returns a clone of the instance in the non-UTC (local) mode.isUTC()checks, if the instance is in the UTC mode.utcOffset()returns the time zone offset to UTC consistently withDate.prototype.getTimezoneOffset()Differences to the "normal" (local) dayjs mode
year(),month()etc. return UTC parts usingDate.propertotype.getUTC*()methods.set(),add()etc. - work with the UTC values of the date parts, as the getters mentioned above.format()method uses the UTC getters too and always formats the time zone as "+00:00".utcOffset()method always returns zero.If a Day.js instance is constructed without the time part, it will appear, as if the instance runs in a "date-only" mode, where no conversion from UTC to the local time takes place, like the
Dateinstance would do it. It can be used for attributes, where the time does not make sense and only the date should be maintained. If only the date applies, it should not be affected by time zone changes.