On Mon, Oct 05, 2020 at 12:05:40PM +0300, Jean Louis wrote:
> * Yuri Khan <yuri.v.khan@gmail.com> [2020-10-04 21:42]:
> > I think tomas’s remark was about the fact that you hardcode +03 in
> > your format string but you let Emacs auto-detect your local time zone.
> > This can cause an inconsistency if it detects a zone other than +03.
> > Two better options would be:
> > 
> > a. Let Emacs auto-detect the time zone and use the %Z format specifier
> > to preserve the detected time zone in the string.
> > 
> >     (format-time-string "%F %T.%6N%Z" (/ 1599549641372 1000.0))
> >     ⇒ "2020-09-08 14:20:41.371999+07"
> 
> Thank you.
> 
> It is not good to hard code in my specific case, and also not good to
> assume the default local time zone as messages are coming from various
> countries in various time zones, it is not practical that I assume my
> local time zone, so I am waiting for the answer from developers of
> Silence SMS application, as maybe the time is UTC time, then it will
> be alright, then I can convert it properly to PostgreSQL timestamp
> with time zone.

I think you don't need that response. They'd be foolish to have a purely
numerical timestamp be other than "seconds [1] from Epoch, in UTC", where
Epoch is 1970-01-01 (well Mac has Epoch on 1900-01-01: whether that's
foolish is left as an exercise to the reader).

Simply because there's no means to communicate.

Typically when /displaying/ the date to a human reader, you pick this
human reader's timezone (or whatever you guess her timezone is).

Cheers

[1] well, milliseconds in your case. Thank Java for it!

 - t