Could someone confirm if the following setup is reliable in providing the same date for all users regardless of timezone?
I have a date picker that makes the following change:
Unix (number field): UNIX Converter (@jarrad’s) convert date to timestamp (this datepicker’s value formatted as yyy-mm-dd hh-mm-ss) this gives the UTC unix stamp.
the initial content for the date picker is: current date, changed to 1970-1-1 + seconds Unix (the utc timestamp)
This looks like it is giving consistent results, but I sometimes see glitches although Ihave a feeling this is more to do with the pc timezone changes not being properly digested by the browser at times.
I had a far more complex setup with the default unix extractor but that gave unix in local timezone and I had it looking OK with a browser offset value (using moment.js) until DST hit and everything was off by an hour, effectively meaning the dates could be off by a day.
I looked at moment.tz (timezone) and got that working, but I feels overkill for what I need.
Anyway, if someone could provide some feedback for this setup, that would be much appreciated. I’m getting really annoyed with time zones at the moment
When you change the date to jan 1 1970 are you also changing hour 00 min 00 and sec 00? If not this could be were your seeing some differences along the line.
But to answer your question, yes getting the utc time as unix and adding it to to the start of the unix time systems date and time will provide the same result for all users. Just like utc as a date and time is the same for all users.
I didn’t know your UNIX plugin actually retrieves the UTC time from a date picker as opposed to the extract UNIX default action which retrieves the unix local time. I had the browser offset added to that UNIX time to make sure the date looked the same for all users.
However, with DST the offset changed for some locations, resulting in an hour difference (thus a day)
