timezone-offset

Time zone conversion in SQL query

谁都会走 提交于 2019-12-01 03:59:07
I am using a query to get some application Received Date from Oracle DB which is stored as GMT. Now I have to convert this to Eastern standard/daylight savings time while retrieving. I am using the below query for this: select to_char (new_time(application_recv_date,'gmt','est'), 'MON dd, YYYY') from application It works fine for Standard time. But for daylight savings time we need to convert it to 'edt' based on timezone info. I am not very sure on how to do this. Please help me out You can use this query, without having to worry about timezone changes. select to_char(cast(application_recv

TZupdater failing with tzdata2016g release

牧云@^-^@ 提交于 2019-12-01 03:38:06
TZUpdater 2.1.0 is failing with tzdata2016g release. For Java 8 it fails with "Source directory does not contain file: VERSION" error, while it completes with "JRE updated to version : tzdataunknown" comment for Java 7. The reason of this seems to be recent change of IANA tzdata distribution: Unsetting VERSION field of Makefile. There is a bug reported regarding the issue: https://bugs.openjdk.java.net/browse/JDK-8166928 . DST date(30th October 2016) is getting closer and we at least need a workaround for this. Is it, somehow, possible? Workaround: Update Makefile of http://www.iana.org/time

Java 8 Offset Date Parsing

无人久伴 提交于 2019-12-01 03:30:58
I need to parse a String in the following format 2015-01-15-05:00 to LocalDate(or smth else) in UTC. The problem is that the following code: System.out.println(LocalDate.parse("2015-01-15-05:00", DateTimeFormatter.ISO_OFFSET_DATE)); outputs 2015-01-15 ignoring the offset. The desired output is 2015-01-16 Thanks in advance! The simplest answer is to use OffsetDateTime to represent the data, but you need to default the time: DateTimeFormatter fmt = new DateTimeFormatterBuilder() .append(DateTimeFormatter.ISO_OFFSET_DATE) .parseDefaulting(ChronoField.HOUR_OF_DAY, 0) .toFormatter(); OffsetDateTime

Time zone conversion in SQL query

折月煮酒 提交于 2019-11-30 23:48:40
问题 I am using a query to get some application Received Date from Oracle DB which is stored as GMT. Now I have to convert this to Eastern standard/daylight savings time while retrieving. I am using the below query for this: select to_char (new_time(application_recv_date,'gmt','est'), 'MON dd, YYYY') from application It works fine for Standard time. But for daylight savings time we need to convert it to 'edt' based on timezone info. I am not very sure on how to do this. Please help me out 回答1: You

Identifying time zones in ISO 8601

柔情痞子 提交于 2019-11-30 17:14:25
No, I'm not talking about zone offsets --- those can vary during the year for a region based on e.g. DST. I'm talking about the actual time zones maintained by IANA . I understand these are not supported by ISO 8601, correct? What are platforms doing to support identifying time zones in ISO 8601-like string representations? I notice that the latest Java date/time library is using an extended ISO 8601 format for this, e.g. 2011-12-03T10:15:30+01:00[Europe/Paris] . (See DateTimeFormatter API .) Is there some converging convention (e.g. with other languages and platforms) for extending ISO 8601

Java doesn't have information about all IANA time zones

限于喜欢 提交于 2019-11-30 15:29:42
问题 I'm trying to map the values that come from the Front-End to ZoneId class like this: Optional.ofNullable(timeZone).map(ZoneId::of).orElse(null) For most time zones it works fine, however, for some values Java throws exception: java.time.zone.ZoneRulesException: Unknown time-zone ID: America/Punta_Arenas However, it is a valid time-zone according to IANA: https://www.iana.org/time-zones Zone America/Punta_Arenas -4:43:40 - LMT 1890 I was thinking about using offset for such time-zones (just to

Java doesn't have information about all IANA time zones

依然范特西╮ 提交于 2019-11-30 14:13:32
I'm trying to map the values that come from the Front-End to ZoneId class like this: Optional.ofNullable(timeZone).map(ZoneId::of).orElse(null) For most time zones it works fine, however, for some values Java throws exception: java.time.zone.ZoneRulesException: Unknown time-zone ID: America/Punta_Arenas However, it is a valid time-zone according to IANA: https://www.iana.org/time-zones Zone America/Punta_Arenas -4:43:40 - LMT 1890 I was thinking about using offset for such time-zones (just to hardcode values), but I guess there should be more convenient way to solve the issue. Is there a way

ISO 8601 date-time format combining 'Z' and offset of '+0000'

隐身守侯 提交于 2019-11-29 23:39:55
问题 I'm playing with date-time format from ISO 8601. I have this pattern: "yyyy-MM-dd'T'HH:mm:ssZZ'Z'" and the output is: "2015-11-17T00:00:00+0000Z" . My question is if the output is ok, if is possible to have in a date +0000 and Z taking in account both has the same meaning time zone offset/id. Thanks in advance for clarification =) 回答1: No, not OK No, the Z is an offset-from-UTC so it should not be combined redundantly with a numerical offset of +00:00 or +0000 . ISO 8601 While I do not have

Identifying time zones in ISO 8601

这一生的挚爱 提交于 2019-11-29 16:47:55
问题 No, I'm not talking about zone offsets --- those can vary during the year for a region based on e.g. DST. I'm talking about the actual time zones maintained by IANA. I understand these are not supported by ISO 8601, correct? What are platforms doing to support identifying time zones in ISO 8601-like string representations? I notice that the latest Java date/time library is using an extended ISO 8601 format for this, e.g. 2011-12-03T10:15:30+01:00[Europe/Paris] . (See DateTimeFormatter API.)

Converting between time zones with Noda Time

*爱你&永不变心* 提交于 2019-11-29 12:17:12
问题 I'm currently trying to ensure that our legacy back-end can support resolving date times based on the user's current time zone (or, more specifically offset). Our servers are in eastern standard time, and most of our date times originate there. However, for users that are in other time zones, a conversion to their time zone (or, in this case, offset) is needed when retrieving those date times. Also, date times coming from the user will have to be converted to eastern standard time before