0

Has anyone experienced different time zones when using momentjs versus date object in a chrome desktop and mobile?

When I execute the following in my desktop the result is OK

moment(moment('01-01-1900', 'DD-MM-YYYY').format()).toDate()

Mon Jan 01 1900 00:00:00 GMT+0000 (GMT Standard Time)

But when in chrome mobile, the date loses about 7 minutes:

moment(moment('01-01-1900', 'DD-MM-YYYY').format()).toDate()

Sun Dec 31 1899 23:53:15 GMT-0036 (Hora padrão da Europa Ocidental)

I am using this library as part of a application and user 1900 as the default date (as null) in my code. For now I have overcome this issue by using 1970 as a default year and it appears to yield the correct results.

Any help appreciated. Thanks.

M Vaz
  • 23
  • 4
  • ECMA-262 now requires Dates to observe historical timezone offsets. For example, in Australia the [*current timezones*](https://en.wikipedia.org/wiki/Time_in_Australia) were adopted on 1 January, 1895. Before then, the offsets were different so that in Brisbane prior to 1895 the offset was GMT+10:12:08, but on 1 January 1895 it was changed to +10:00. See [*Browsers, time zones, Chrome 67 Error*](https://stackoverflow.com/questions/50609860/browsers-time-zones-chrome-67-error) (of which this is likely a duplicate). – RobG Jun 09 '18 at 13:11
  • I think "Hora padrão da Europa Ocidental" is Portugese for "Western Europe Time", which was adopted by Portugal on 26 May, 1911. Prior to that, it used an offset of GMT–00:36:44 (see [*Time in Portugal*](https://en.wikipedia.org/wiki/Time_in_Portugal)). So there is likely nothing wrong with Chrome or moment.js, they're just doing what they're supposed to and applying historical timezones to dates as required by [*ECMA-262*](http://ecma-international.org/ecma-262/8.0/#sec-local-time-zone-adjustment) which links to the [*IANA Time Zone Database*](https://www.iana.org/time-zones). – RobG Jun 09 '18 at 13:25
  • Thanks RobG, the thing I find odd is getting a different date when parsing and unparsing, so it appears that the browser is using different offsets when converting from and to js date objects. – M Vaz Jun 09 '18 at 13:27
  • Dates need careful consideration. Sometimes you want to adjust for local time zones and sometimes you don't. E.g. someone born in New York at 11pm on 1 Jan 1990 doesn't change their date of birth to 2 Jan when in London, even though that was the date in London when they were born. As for serialising and parsing dates, don't do that. It's hard to recommend a suitable strategy for your case without knowing what you're doing and why. Using a valid date for "null" doesn't seem to be a good idea though. – RobG Jun 09 '18 at 13:33
  • Appreciate your insights Rob, thanks again. I am using all this in a angular app that uses a TimePicker that must receive a js Date Object. Although i the end I just store the Time (ex: "12:30"), I must supply the picker with some date object. It was in this process that the application was entering a Loop losing 7 minutes when supplied the date to the component, that in hand, informed the app that the selected value had changed triggering a new setValue in the component. In the end I refactored the App so that it uses a more recent Date part internally that allowed me to overcome the issue. – M Vaz Jun 09 '18 at 13:42

0 Answers0