UnixTime plugin problem

[lechao255]

I am using the popclip plugin, thank you very much for your development, there is a question about the UTC plugin, can you read the local time zone like the timestamp plugin. Thank you very much if you can solve it 🙏

[pilotmoon]

Isn't the thing about Unix timestamp that it is always based on UTC? Making it timezone relative would make it ambiguous which defeats a main benefit of a Unix timestamp....

[lechao255]

I'm in Beijing, China now, but the date fetched by timestamp always differs by 8 hours

[pilotmoon]

That is the expected behaviour. The result of the UnixTime extension should be exactly the same everywhere in the world. It is defined as the number of seconds since 00:00:00 1/1/1970 UTC*. Unix time is not a local time.

*excluding leap seconds....

[lechao255]

Indeed, as you said, UnixTime is the same all over the world, but when it is converted into date and time, it must be calculated according to the local time zone, such as at this moment, although the timestamps we get are the same, but we The datetime is timezone difference...

[lechao255]

Hahaha, so I hope you can optimize it to be better~ Because I think this plugin is very convenient, thank you very much for your development

[lechao255]

Does this plugin have a time zone setting?

[pilotmoon]

No, it doesn't have any settings.

[pilotmoon]

It's actually still in PHP so I need to rewrite it in JavaScript anyway... so I'll try and add this in when I do it.

[lechao255]

I think it is possible to do this, in the PHP file, read \etc\localtime to set the time zone (date_default_timezone_set), so that it can be consistent

[pghk]

I've done some work on rewriting this in JavaScript; I can open a PR if you'd like!

I'm not sure how you'd want the localization enhancement handled, though:

• Should it still default to the current behavior? (involves some odd stuff, see below)
• Should manual entry of locales & timezones be allowed? (risk of user error)
  • or should lists of those options be provided by the plugin? (somewhat unwieldy, maintenance burden)

The current behavior can be replicated with something like this:

let fromUnix = new Date(1535438729 * 1000)
let [date, _, time] = fromUnix.toISOString().split(/(\.|T)/)
`${date} ${time} UTC`
// "2018-08-28 06:45:29 UTC"

With a customizable system

// for Intl.DateTimeFormat
let options = {
  year: "numeric",
  month: "2-digit",
  day: "2-digit",
  hour: "2-digit",
  minute: "2-digit",
  second: "2-digit",
  hour12: false,
  timeZoneName: 'short',
}

Default option

The current behavior would require setting a locale which just happens to use YYYY-MM-DD, rather than one which is actually true for the user, (because reasons). Something like one of these:

new Intl.DateTimeFormat("en-CA", {timeZone: "UTC", ...options}).format(fromUnix).replace(',', '')
// "2018-08-28 06:45:29 UTC"
new Intl.DateTimeFormat("af", {timeZone: "UTC", ...options}).format(fromUnix)
// "2018-08-28 06:45:29 UTC"

System option

An empty array of locales and no timeZone key under 'options' yields something akin to "use current location" perhaps:

new Intl.DateTimeFormat([], options).format(fromUnix)
new Intl.DateTimeFormat("en-US", {timeZone: "America/New_York", ...options}).format(fromUnix)
// "08/28/2018, 02:45:29 EDT"

Mix-and-match option

There are various ways that locales handle naming local vs non-local timezones:

new Intl.DateTimeFormat("af", {timeZone: "America/New_York", ...options}).format(fromUnix)
// "2018-08-28 02:45:29 GMT-4"
new Intl.DateTimeFormat("zh", {timeZone: "America/New_York", ...options}).format(fromUnix)
// "2018/08/28 GMT-4 02:45:29"
new Intl.DateTimeFormat("fr-CH", {timeZone: "America/New_York", ...options}).format(fromUnix)
// "28.08.2018, 02:45:29 UTC−4"
new Intl.DateTimeFormat("zh-HK", {timeZone: "America/New_York", ...options}).format(fromUnix)
// "28/08/2018 02:45:29 [EDT]"
new Intl.DateTimeFormat("zh", {timeZone: "Asia/Shanghai", ...options}).format(fromUnix)
// "2018/08/28 GMT+8 14:45:29"
new Intl.DateTimeFormat("af", {timeZone: "Africa/Johannesburg", ...options}).format(fromUnix)
// "2018-08-28 08:45:29 SAST"

So in order to get something localized but otherwise in the style of the current behavior, what I would do is:

new Intl.DateTimeFormat("en-CA", options).format(fromUnix).replace(',', '')
// "2018-08-28 02:45:29 EDT"

[pilotmoon]

That's some nice work. I was originally thinking the default ought to be to continue with UTC by default, and a check box for "display in local timezone", default off. But this is not currently possible because I don't think the local time zone detection works in PopClip's JS environment. (Or does it??) I'm not actually sure what the result of functions that assume a default timezone / locale etc is inside PopClip's JS environment. - This is a capability I would like to improve and document.

So instead we might need a list of timezones as you say. As to whether it's hardcoded or procedural generated, either would be acceptable (options can now be generated in code, for example the Quotes extension).

Feel free to PR whatever code you think might do the trick. If you don't mind me messing it up later :)

[pghk]

I don't think the local time zone detection works in PopClip's JS environment. (Or does it??)

It does seem to, in my experience. The relevant functions don't require timezone or locale in their input, and I get the same result omitting them as I do when supplying the correct ones.