Short answer: you can’t. Daylight saving time make it impossible. For example, there is no way to determine, solely from UTC offset, the difference between Arizona and California in the summer, or Arizona and New Mexico in the winter (since Arizona does not observe DST). There is also the issue of what time different countries … Read more
Java: int offset = TimeZone.getDefault().getRawOffset() + TimeZone.getDefault().getDSTSavings(); long now = System.currentTimeMillis() – offset; Kotlin: val offset: Int = TimeZone.getDefault().rawOffset + TimeZone.getDefault().dstSavings val now: Long = System.currentTimeMillis() – offset
I would use my Noda Time project personally. (Admittedly I’m biased as the author, but it would be cleaner…) But if you can’t do that… Either use DateTime.ParseExact specifying the exact format you expect, and include DateTimeStyles.AssumeUniversal and DateTimeStyles.AdjustToUniversal in the parse code: using System; using System.Globalization; class Test { static void Main() { var … Read more
[NSDate date]; You may want to create a category that does something like this: -(NSString *)getUTCFormateDate:(NSDate *)localDate { NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init]; NSTimeZone *timeZone = [NSTimeZone timeZoneWithName:@”UTC”]; [dateFormatter setTimeZone:timeZone]; [dateFormatter setDateFormat:@”yyyy-MM-dd HH:mm:ss”]; NSString *dateString = [dateFormatter stringFromDate:localDate]; [dateFormatter release]; return dateString; }
Hugo’s answer is mostly correct, but I’ll add a few key points: When you’re storing the customer’s time zone, do NOT store a numerical offset. As others have pointed out, the offset from UTC is only for a single point in time, and can easily change for DST and for other reasons. Instead, you should … Read more
I think I got it: pytz.utc.localize(utc_time, is_dst=None).astimezone(tz) This line first converts the naive (time zone unaware) utc_time datetime object to a datetime object that contains a timezone (UTC). Then it uses the astimezone function to adjust the time according to the requested time zone.
System.currentTimeMillis() does give you the number of milliseconds since January 1, 1970 00:00:00 UTC. The reason you see local times might be because you convert a Date instance to a string before using it. You can use DateFormats to convert Dates to Strings in any timezone: DateFormat df = DateFormat.getTimeInstance(); df.setTimeZone(TimeZone.getTimeZone(“gmt”)); String gmtTime = df.format(new … Read more
In Python 3.x, local timezone can be figured out like this: >>> import datetime >>> print(datetime.datetime.now(datetime.timezone.utc).astimezone().tzinfo) AEST It’s a tricky use of datetime‘s code . For python < 3.6, you’ll need >>> import datetime >>> print(datetime.datetime.now(datetime.timezone(datetime.timedelta(0))).astimezone().tzinfo) AEST
JavaScriptSerializer, and DataContractJsonSerializer are riddled with bugs. Use json.net instead. Even Microsoft has made this switch in ASP.Net MVC4 and other recent projects. The /Date(286769410010)/ format is proprietary and made up by Microsoft. It has problems, and is not widely supported. You should use the 1979-02-02T02:10:10Z format everywhere. This is defined in ISO8601 and RF3339. … Read more
I know I’m five years late, but I had the same problem tonight. In my experience, the solution to the problem was to use the aware UTC datetime: utc_dt_aware = datetime.datetime.now(datetime.timezone.utc) If you google “utcnow() wrong” this is the first result you get, so I thought it would be good to answer anyway.