Support non-milli Unix timestamps

[alert-debug]

I've had another idea that I think might make this tool even more convenient. The idea actually occurred to me when I made a mistake in copy-pasting a timestamp from an online converter into the .nsprc config file, so I think other users may encounter the same problem, but I'm happy to report that the list of exceptions table helped me to work out what I did wrong, so this is not a major issue.

Basically, the expiry field in the config file requires a Unix timestamp in milliseconds, and I think the tool should detect dates before 1971 and interpret them as Unix timestamps in seconds. Even better would be to support other formats for the expiry field, such as YYYY-MM-DD date strings, and any other format that isn't ambiguous and doesn't complicate the parsing logic too much.

As a related aesthetic/usability change, you might want to style the expired text as yellow if the expiry date was less than a year ago, and red if it was much longer, as that might suggest the user has made a mistake. Similarly, for expiry dates in the future, it might be worth styling the active text as yellow if the date is more than 5(?) years in the future, as that sort of defeats the point of having an expiry at all and again could be due to a typo.

[jeemok]

I think that's a good idea, using Unix timestamp might not be user-friendly after all; and I agree to the overlong expiry date! it kinda encourages more people to ignore and leave it there after. I will work on this probably over next weekend 👍🏻

[jeemok]

hey, @alertme-edwin I have extended the expiry date feature and publish it into v3.1.0, please try it out!

[alert-debug]

My .nsprc file now looks so readable that the tool is almost self-documenting. 😄 Seriously, I think this package has one of the best developer-experiences in the whole of NPM. Thank you so much for this.

[jeemok]

Glad to hear that! Thank you too for contributing the ideas on how to make this tool a better one! 👍🏻