Does Utc Observe Daylight Saving Time

Is there a way to check if it's DST (Daylight Saving Time) with UTC?

Just use TimeZoneInfo.IsDaylightSavingTime, passing in your UTC DateTime value. That will effectively convert that UTC value into the given time zone and check whether the result is in daylight saving time, although whether it actually performs that conversion or just checks whether it would be in DST is a different matter.

Note that this is never ambiguous, as a UTC value is never ambiguous.

TimeZoneInfo.IsDaylightSavingTime returns true when passed 2018-10-28T00:00:00Z in the time zone you're interested in.

Is Windows UTC time Daylight-saving independent?

There is no such thing as daylight savings time in UTC.

However, there are occasional leap seconds. The last leap second was added on June 30, 2012 at at 23:59:60 UTC. Time at the end of that day went from 23:59:59 to 23:59:60 before going to 00:00:00 July 31, 2012.

Use something such as Atomic Time if you want a leap-second free time standard.

How to convert local time to UTC, considering daylight saving time?

Assuming Local contains date/time as observed locally, i.e. including DST active/inactive, you would convert to datetime object, set time zone, and convert to UTC.

Ex:

from datetime import datetime, timezone
from zoneinfo import ZoneInfo # Python 3.9

Local = ["2018/07/20 09:00", "2018/12/31 11:00", "2019/01/17 13:00", "2020/08/15 18:00"]

# to datetime object and set time zone
LocalZone = ZoneInfo("Europe/Vienna")
Local = [datetime.strptime(s, "%Y/%m/%d %H:%M").replace(tzinfo=LocalZone) for s in Local]

for dt in Local:
    print(dt.isoformat(" "))
# 2018-07-20 09:00:00+02:00
# 2018-12-31 11:00:00+01:00
# 2019-01-17 13:00:00+01:00
# 2020-08-15 18:00:00+02:00

# to UTC
UTC = [dt.astimezone(timezone.utc) for dt in Local]

for dt in UTC:
    print(dt.isoformat(" "))
# 2018-07-20 07:00:00+00:00
# 2018-12-31 10:00:00+00:00
# 2019-01-17 12:00:00+00:00
# 2020-08-15 16:00:00+00:00

Note: with Python 3.9, you don't need third party libraries for time zone handling in Python anymore. There is a deprecation shim for pytz.

Weird as.POSIXct behavior depending on daylight savings time

if you really want it printed with the times you can always do.

as.POSIXct("26/03/2006 02:05:38", format="%d/%m/%Y %H:%M:%S", tz = "UTC")
#[1] "2006-03-26 02:05:38 UTC"

Just make sure you do this for all conversions for consistency.

As Wikipedia states:

UTC does not change with a change of seasons, but local time or civil
time may change if a time zone jurisdiction observes daylight saving
time (summer time). For example, local time on the east coast of the
United States is five hours behind UTC during winter, but four hours
behind while daylight saving is observed there.

Difference between UTC, GMT and Daylight saving time in JS

UTC is a standard, GMT is a time zone. UTC uses the same offset as GMT, i.e. +00:00. They are essentially interchangeable when discussing offsets.

All javascript (ECMAScript) Date objects use a time value that is UTC milliseconds since 1970-01-01T00:00:00Z. When the Date constructor is called without any arguments, it gets the time and time zone offset from the host system and calculates the time value. Therefore, the accuracy of the generated date depends on the accuracy of those components.

When outputting date values using the UTC methods (e.g. getUTCHours, getUTCMinutes, etc.), the vaules are UTC (GMT). When not using those methods (e.g. getHours, getMinutes, etc.) the host system time zone offset is used with the time value to generate "local" values from the UTC time value.

Whether daylight saving is applied or not depends on the host system settings. Whatever the current rules are for the host system time zone changes for daylight saving are applied to all dates, regardless of the actual offset that date (e.g. if currently DST starts on the first Sunday in October then it will be assumed to have always started on the first Sunday in October).

Date object behaviour is described in ECMA-262 §20.3.2 and a bit more clearly (for some parts) in MDN Date.

Amazon summer time reliability

Copied from AWS user guide:

Amazon Linux instances are set to the UTC (Coordinated Universal Time) time zone by default

Furthermore:

Network Time Protocol (NTP) is configured by default on Amazon Linux instances; however, an instance needs access to the Internet for the standard NTP configuration to work. In addition, your instance's security group rules must allow outbound UDP traffic on port 123 (NTP), and your network ACL rules must allow both inbound and outbound UDP traffic on port 123. [...] If your instance does not have access to the Internet, you need to configure NTP to query a different server in your private network to keep accurate time.

UTC and Daylight savings scenario

Those scenarios are cases advocating for the use of DST. It doesn't matter what you display as long as you store and sort values in UTC. That is, if you use UTC properly, the problems presented in those scenarios are solved.

Yes, it would be confusing to see records like this: 12:30, 1:20, 1:10, 3:30 but if that's how they are ordered according to UTC (what really happened), I think that's the right way to do it.

SO avoids this problem altogether by recording everything in UTC and then displaying it all in UTC or relative times (like "17 mins ago...").

If you're referring to user supplied dates/times as suggested in the comments, I have some bad news for you: it sucks. I think the best, most obvious solution is to pick a rule and run with it. If you really do need to handle it perfectly, your UI will need to be expanded to pedantically handle this edge case that occurs a mere 1 hour each year and then only to transactions created not-in-real-time (because if they were real-time, you'd know the DST equivalent).