As it is, it won't matter if your local format is "d/m/yyyy" as "" is the same regardless of the month/day order. Someone asked above "What format should be used for regular date format as there are several used?" You can use "" which Excel should translate reliably. In my case, I decided I did not care if a displayed time was off by an hour should the daylight savings mode be different between "now" and a given Unix time and so using "LocalOffsetFromGMT()/8" works for me. To add to the pain, a few years ago the USA changed the dates we switched to/from daylight savings time. My current GMT offset is 8 hours but during the summer it's 7 hours and so 1314627183 should translate to 07:13:03 for me. We were on daylight savings at the time time. For example, let's say I have 1314627183 which translates to 14:13:03 GMT. The LocalOffsetFromGMT() function on that page works and returns the number of minutes from GMT meaning I divide that by 60 and get the fraction of the day Excel uses.Įven that is not perfect. Unfortunately, discovering the current time zone offset in Excel is a major pain. I'm in Pacific standard time time at the moment and expected to see 12:01:21. If you convert a value such as 1322164881 using =CELL/(60*60*24)+"" you will get 20:01:21 which is correct for UTC or the GMT time zone. Be aware that Unix time is the number of seconds since Janufor UTC/GMT while Excel uses the number of days and fractions of the day for the local time zone.