Perhaps a daft question that demonstrates my lack of understanding of daylight saving fundamentals, but as per the title, how does Time.dst? know whether the time object is indeed true or false?
Presumably this must be discernible by the combination of the Date and the Timezone, but then that doesn't make sense as lower latitudes in timezones don't use daylight savings? Therefore surely it must need location to discern #dst? ?
What am i missing?
To deal with time zones and daylight savings time, Ruby, like just about everything else, is calling the localtime_r C function. This puts the time in a C structure called tm which includes a field called isdst. Ruby is reading that flag.
localtime_r calculates isdst first by getting your time zone from the global tzname variable. tzname is determined by calling tzset. How tzset does its job is system dependent. It can come from the TZ environment variable, reading a file, or querying an OS service.
For example.
# Time zone from the system.
$ ruby -e 'puts Time.now.zone; puts Time.now.dst?'
PDT
true
# Time zone from the TZ environment variable.
$ TZ='Australia/Brisbane' ruby -e 'puts Time.now.zone; puts Time.now.dst?'
AEST
false
Once it has the time zone, localtime_r can convert from GMT to the desired time zone (using the rules which applied on that date) using the "tz database" aka "tzdata" aka "zoneinfo" aka "the Olson database" after its creator Arthur David Olson. Previously a private effort, this is now maintained by IANA. It is a set of files installed on your system, or shipped with Ruby, which contains Far More Than Everything You Ever Want To Know About Time Zones and Daylight Savings.
The tz database treats daylight savings (and other weird things like War and Peace time) as just another time zone. Time zone records are kept going all the way back as far as we've had time zones. Before we had time zones solar noon for that location is used. Because of these historical complications and shifting time zones, the tz database prefers to work with cities (such as "America/New York") and determine the time zone for you.
The time zone data files contain extensive commentary and background, if you're interested in the history of calendaring they're a fascinating read.
The Ruby 2.2.0 Time.dst? method refers to the time_isdst(...) function in time.c:
// ...
return tobj->vtm.isdst ? Qtrue : Qfalse
Which seems correspond to the UNIX struct tm tm_isdt member, after plenty of mangling:
int tm_isdst daylight savings flag
Search for tm_isdst and isdst in time.c to read about how it is computed.
Related
I ran into an issue with Go code, related to time zones, that would return either 1900-01-01 01:00:00 +0100 CET or 1900-01-01 00:53:28 +0053 LMT, depending on which machine it is being run:
https://play.golang.org/p/K3ceq1n1KI
I was able to rule out the Go version as source of the difference. Where does Go get its time zone information from?
Actually it depends.
Check time.LoadLocation() source and the comment above it. Particularly, it says this:
// LoadLocation looks in the directory or uncompressed zip file
// named by the ZONEINFO environment variable, if any, then looks in
// known installation locations on Unix systems,
// and finally looks in $GOROOT/lib/time/zoneinfo.zip.
And you should keep in mind that on a Unix/Posix systems (e.g. Linux), proper time zone data files are always available in "known installation locations". But on other systems there no such locations. As a result, on Windows, LoadLocation zone won't find any time zones (unless either ZONEINFO or GOROOT were configured properly) and will just use default instead (which is UTC, if my memory is correct).
However, the LMT issue you described above is a bit different beast. You see, LMT is not exactly a proper time zone. E.g. see here. And I didn't dig out where exactly it comes from, but I suspect it is related to the fact that the time zone was not established yet at the time that you're converting. So, go seems to be calculating LMT of the place instead.
For example, if you just change year from 1900 to 2000 (or even 1905) in your playground example, it will come out with correct time zone (CET).
As to the difference between machines, I'd say it's pretty arguable what is the most natural way of defining time zone rules before they were actually introduced. As a result, I would imagine that in some time zone databases, start time of the first rule in a time zone will be either omitted or adjusted to extend it further to the past. While others will put an LMT offset there instead. (Even though most if not all of them are derived from the same IANA database in one way or another.)
If you want to ensure exact same behavior on different machines, I'd say building your own zoneinfo.zip and setting ZONEINFO variable should help.
Banging my head on this simple date logic problem:
I know the user's time zone offset relative to UTC.
My server is in UTC. It knows the time now.
How do I calculate UTC equivalent of 'yesterday local time at 8am'?
IN JS, I tried to do it this, but it seems to not quite work.
var yesterday_am=moment(moment(new Date()).subtract(24,'hour')).format('YYYY-MM-DD'); // same local time previous day;
// when is 8am local time in utc?
var am=8 - (user.tz_offset/60);
if (am<0) { yesterday_am=moment(yesterday_am).subtract(Math.abs(am), 'hour')};
if (am>0) { yesterday_am=moment(yesterday_am).add(am, 'hour')};
For example, if UTC is 2016-01-10 0235 and local time is -7 hours, it would output 2016-1-09 1500 (8am local).
The logic you are trying to perform is impossible. Without knowing the user's actual time zone, you cannot know the UTC equivalent of 'yesterday at 8 am' local time. Daylight saving time transitions may make the offset yesterday different than the offset today. See the time zone tag wiki, particularly the Time Zone != Offset section for more information.
If you do know the user's time zone, then you can perform this calculation using the moment timezone add-on library for Moment.js. The code would be as follows:
moment().tz('America/Los_Angeles').subtract(1, 'day')
.set({hours:8, minutes:0, seconds:0, milliseconds:0}).utc()
Breaking this down so it makes sense, we are doing the following things:
moment() //get the current time
.tz('America/Los_Angeles') //put the moment in the Los Angeles time zone
//the Los Angeles time zone is one of several that are UTC-7 right now
.subtract(1, 'day') //go to yesterday
.set({hours:8, minutes:0, seconds:0, milliseconds:0}) //set the time to exactly 8 am
.utc() //convert back to UTC
Do not add 8 hours to the start of the day. This will be 9 AM if the clocks 'sprang forward' that day, and 7 am if they 'fell back'.
It sounds like your code is running in Node on the server. If it is running in the browser, then the browser knows the user's time zone rules, and you could use the following code to get the time at 8 am yesterday:
moment().subtract(1, 'day').set({hours:8, minutes:0, seconds:0, milliseconds:0}).utc()
This code does not require the moment timezone add on because the browser knows the time zone rules for the user's local time.
If you need to get the user's time zone, you have a few options. The most reliable is to use a timezone picker built into a map to let the user choose. There are a few of these floating around the internet.
If you do not want to do that, you can use the moment.tz.guess() function to have moment timezone make an educated guess about the user's time zone using some heuristics. This function is good, but due to limitations of the browser it is impossible to make it 100% accurate.
For a whole bunch of information about handling date and time and time zones in JavaScript, you can try this talk I did at JavaScript MN a few months ago.
In addition, you might like this really excellent Pluralsight course by Matt Johnson.
This code is not DST aware (in case if you've not already figure out based on the comments below). Thank you Maggie. Please refer to complete answer from Maggie.
You can do something like this
var localTime = moment.utc("2016-06-19").utcOffset('-07:00');
var utcAt8PrevDay = moment(localTime).subtract(1,'days').startOf('day').add(8, 'hour').utc();
I am playing around with timezone and noticed something wierd.
I am currently in the BST timezone which is an hour ahead of GMT.
now := time.Now()
location, _ := time.LoadLocation("Atlantic/Cape_Verde")
timeAtZone := now.In(location)
fmt.Println(timeAtZone)
timestamp = timeAtZone.Unix()
fmt.Println(timestamp)
fmt.Println(now.Add(-time.Hour).UTC().Unix())
fmt.Println(now.UTC().Unix())
You will notice that the timestamp is that of BST my current timezone.
How do I get the timestamp of GMT???
http://play.golang.org/p/oq0IRYa0h7
Unix time is absolute. There is no "BST Unix time." There is no "Atlantic/Cape_Verde" Unix time." There is only Unix time. It is the number of seconds since a specific moment (00:00:00 Coordinated Universal Time (UTC), Thursday, 1 January 1970, not counting leap seconds).
Time zones are related to the representation of time, not time itself. It is the same moment for you as it is for me, wherever we are in the world (leaving Einstein aside for the moment). We just happen to call that moment different things. Setting the location on a *Time just indicates how you would like to display the time. So if by "timestamp" you mean "string representing the time," you can get the UTC timestamp with time.Now().UTC().String().
Make sure you check your errors, I assume it's telling you there's an issue.
Have you checked: http://golang.org/pkg/time/#LoadLocation
Is your timezone in: $GOROOT/lib/time/zoneinfo.zip?
For me:
time.LoadLocation("CDT") // my time zone
time.LoadLocation("CST")
Both result in an error.
To get my time zone, I must do:
time.LoadLocation("America/Chicago")
Make sure f.Timezone is valid.
I'm attempting to convert a time from UTC to the Phone's local time. For this I'm using the following:
if (progress.ActionDateTime.HasValue)
progress.ActionDateTime = TimeZoneInfo.ConvertTime(progress.ActionDateTime.Value, TimeZoneInfo.Local);
However, the time remains exactly the same after the conversion has took place. Is this method working in WP7?
A DateTime does not store information about the time zone. According to the documentation, TimeZoneInfo.ConvertTime will use the DateTime.Kind property to determine how the time should be converted:
DateTimeKind.Local and DateTimeKind.Unspecified: Converts the local time to the time in destinationTimeZone.
DateTimeKind.Utc: Converts Coordinated Universal Time (UTC) to the time in destinationTimeZone.
Since you're using TimeZoneInfo.Local for the second parameter (which specify the destination time zone), I'm assuming that you're DateTimeKind is either Local or Unspecified. Therefore, you're converting a local date to a local date, which obviously won't work.
DateTime.ToLocalTime also uses the DateTimeKind. According to the documentation:
Utc: This instance of DateTime is converted to local time.
Local: No conversion is performed.
Unspecified: This instance of DateTime is assumed to be a UTC time, and the conversion is performed as if Kind were Utc.
Basically, while TimeZoneInfo.ConvertTime considers that DateTimeKind.Unspecified = Local, DateTime.ToLocalTime considers that DateTimeKind.Unspecified = Utc. It explains why the latter works while the former doesn't.
I've got Time objects that I'm writing to an Excel file. I'm using the axlsx library. The class that converts dates to the cell data is DateTimeConverter, which turns it into a float timestamp.
The times are displayed as mm/DD/YYYY HH:MM:SS as expected, but the values are in GMT time.
Is there a way to make Excel format the times for a particular time zone, or the reader's local timezone? My current solution is to export the formatted time as a string, and I am dissatisfied with this.
Is there a way to do this without adding a VBA macro? (Please note that I'm not trying to convert the local time to GMT with a VBA macro as per the linked "duplicate" question, but rather display the GMT time to a local time - preferably without a VBA macro, if possible.)
Short answer
Excel timestamps don't know anything about time zones. If you want to export a value and display it in local time, you need to add the utc_offset to the time before you send it to Axlsx.
t = ...
excel_time = Time.at(t.to_f + t.utc_offset)
sheet.add_row ["Time:", excel_time]
Long answer
In Ruby (and many other programming languages) timestamps are represented as the number of seconds since Jan 1, 1970 00:00:00 UTC (the epoch). The Ruby Time object also retains a time zone, so that when you print it out it can display the local time. If you change the time zone, the time will be printed out differently, but the underlying number stays the same.
In Excel, timestamps are represented as the number of days since Jan 1, 1900 (or 1904, depending on the workbook settings); time is indicated as a fractional part of a day. If today's date is 41262, then 12am is 41262.0 and noon is 41262.5. There are no time zones in this scheme, time is simply a number you read off your watch.
When Axlsx exports a Ruby Time object to Excel, it calls to_f to get the time value in seconds since the epoch, then does some math to convert that to the serial number that Excel likes. Great! But it threw away the utc_offset, which is why the times are appearing in Excel as UTC.
The solution is to simply add the UTC offset to the times in your code, before you hand them over to Axlsx. For example, if you are on Eastern Standard Time, you must subtract five hours. Technically, the new time object you are creating is incorrect as far as Ruby is concerned, but we're just doing this to please Excel.